Manual Monitoring Application Servers

User Manual: Monitoring Application Servers

Open the PDF directly: View PDF .
Page Count: 522

Download
Open PDF In Browser	View PDF

Monitoring Application Servers
eG Enterprise v6.0

Restricted Rights Legend
The information contained in this document is confidential and subject to change without notice. No
part of this document may be reproduced or disclosed to others without the prior permission of eG
Innovations Inc. eG Innovations Inc. makes no warranty of any kind with regard to the software and
documentation, including, but not limited to, the implied warranties of merchantability and fitness for
a particular purpose.
Trademarks
Microsoft Windows, Windows NT, Windows 2003, and Windows 2000 are either registered trademarks
or trademarks of Microsoft Corporation in United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Copyright
©2014 eG Innovations Inc. All rights reserved.

Table of Contents
INTRODUCTION ................................................................................................................................................................................................... 1
MONITORING WEBLOGIC APPLICATION SERVERS................................................................................................................................. 2
2.1

2.2

MONITORING THE WEBLOGIC SERVER VER. 9.0 (AND ABOVE) .................................................................................................................... 3
2.1.1 The Application Processes Layer .................................................................................................................................................... 4
2.1.2 The JVM Layer ............................................................................................................................................................................... 8
2.1.3 The WebLogic Service Layer ........................................................................................................................................................ 82
2.1.4 The WebLogic Database Layer ................................................................................................................................................... 142
2.1.5 The WebLogic EJB Layer ........................................................................................................................................................... 157
MONITORING THE WEBLOGIC SERVER VER. 6/7/8 ................................................................................................................................... 180
2.2.1 The JVM Layer ........................................................................................................................................................................... 180
2.2.2 The WebLogic Service Layer ...................................................................................................................................................... 181
2.2.3 The WebLogic Database Layer ................................................................................................................................................... 182
2.2.4 The WebLogic EJB Layer ........................................................................................................................................................... 183

MONITORING WEBSPHERE APPLICATION SERVERS .......................................................................................................................... 184
3.1

3.2

MONITORING THE WEBSPHERE APPLICATION SERVER VERSION 4/5.X .................................................................................................... 184
3.1.1 The WebSphere Service Layer .................................................................................................................................................... 185
3.1.2 The WebSphere Database Layer ................................................................................................................................................. 196
3.1.3 The WebSphere EJB Layer ......................................................................................................................................................... 201
3.1.4 The WebSphere Web Layer ......................................................................................................................................................... 206
MONITORING THE WEBSPHERE APPLICATION SERVER 6.0 (AND ABOVE)................................................................................................. 240
3.2.1 The JVM Layer ........................................................................................................................................................................... 241
3.2.2 The WAS Service Layer............................................................................................................................................................... 242
3.2.3 The WAS Database Layer ........................................................................................................................................................... 260
3.2.4 The WAS EJB Layer.................................................................................................................................................................... 264
3.2.5 The WAS Web Layer ................................................................................................................................................................... 278

MONITORING IPLANET APPLICATION SERVERS ................................................................................................................................. 299
4.1

THE NAS SERVICE LAYER ....................................................................................................................................................................... 300
4.1.1 NAS SNMP Test .......................................................................................................................................................................... 300

MONITORING COLDFUSION APPLICATION SERVERS......................................................................................................................... 303
5.1

5.2

THE CF SERVICE LAYER .......................................................................................................................................................................... 304
5.1.1 Coldfusion Test ........................................................................................................................................................................... 304
5.1.2 Coldfusion Log Test .................................................................................................................................................................... 306
THE CF DB ACCESS LAYER ..................................................................................................................................................................... 307

MONITORING SILVERSTREAM APPLICATION SERVERS ................................................................................................................... 309
6.1

THE SILVER STREAM SERVICE LAYER...................................................................................................................................................... 310
6.1.1 SilverStream Test ........................................................................................................................................................................ 310

MONITORING JRUN APPLICATION SERVERS ........................................................................................................................................ 313
7.1
7.2

THE JVM LAYER ...................................................................................................................................................................................... 314
THE JRUN SERVICE LAYER ..................................................................................................................................................................... 314
7.2.1 JRun Threads Test ...................................................................................................................................................................... 315
7.2.2 JRun Service Test........................................................................................................................................................................ 317
7.2.3 JRun Server Test ......................................................................................................................................................................... 319

MONITORING ORION SERVERS .................................................................................................................................................................. 321
8.1

THE JAVA APPLICATION SERVER LAYER .................................................................................................................................................. 321
8.1.1 Java Server Web Access Test ...................................................................................................................................................... 322

MONITORING TOMCAT SERVERS.............................................................................................................................................................. 324
9.1

THE JVM LAYER ...................................................................................................................................................................................... 326
9.1.1 JMX Connection to JVM ............................................................................................................................................................. 326
9.1.2 JVM File Descriptors Test .......................................................................................................................................................... 328
9.1.3 Java Classes Test ........................................................................................................................................................................ 329
9.1.4 JVM Garbage Collections Test ................................................................................................................................................... 332
9.1.5 JVM Threads Test ....................................................................................................................................................................... 339
9.1.6 JVM Cpu Usage Test .................................................................................................................................................................. 345

9.2

9.3

9.1.7 JVM Memory Usage Test ............................................................................................................................................................ 349
9.1.8 JVM Uptime Test ........................................................................................................................................................................ 354
9.1.9 Tests Disabled by Default for a Tomcat Server ........................................................................................................................... 358
THE WEB SERVER LAYER ........................................................................................................................................................................ 370
9.2.1 Tomcat Cache Test..................................................................................................................................................................... 371
9.2.2 TomcatThreads Test.................................................................................................................................................................... 373
THE JAVA APPLICATION SERVER LAYER .................................................................................................................................................. 377
9.3.1 Tomcat Applications Test ............................................................................................................................................................ 378
9.3.2 Tomcat Connectors Test ............................................................................................................................................................. 380
9.3.3 Tomcat Jsps Test ......................................................................................................................................................................... 382
9.3.4 TomcatServlets Test .................................................................................................................................................................... 384

MONITORING SUNONE APPLICATION SERVERS .................................................................................................................................. 387
10.1 THE JVM LAYER ...................................................................................................................................................................................... 388
10.2 THE SUNONE HTTP LAYER .................................................................................................................................................................... 389
10.2.1 SunONE Http Test....................................................................................................................................................................... 389
10.3 THE SUNONE DB LAYER ......................................................................................................................................................................... 391
10.3.1 SunONE Jdbc Test ...................................................................................................................................................................... 391
10.4 THE SUNONE TRANSACTIONS LAYER ..................................................................................................................................................... 392
10.4.1 SunONE Transactions Test ......................................................................................................................................................... 393
10.5 THE SUNONE EJB LAYER........................................................................................................................................................................ 394
10.5.1 SunONE Ejb Cache Test ............................................................................................................................................................. 394
10.5.2 SunONE EJB Pools Test ............................................................................................................................................................. 396
MONITORING ORACLE 9I APPLICATION SERVERS.............................................................................................................................. 399
11.1 THE ORACLE JVM LAYER ........................................................................................................................................................................ 401
11.1.1 Oracle 9i Jvm Test ...................................................................................................................................................................... 401
11.1.2 Java Transactions Test ............................................................................................................................................................... 402
11.1.3 Java Classes Test ........................................................................................................................................................................ 404
11.1.4 JVM Threads Test ....................................................................................................................................................................... 407
11.1.5 JVM Cpu Usage Test .................................................................................................................................................................. 413
11.1.6 JVM Memory Usage Test ............................................................................................................................................................ 417
11.1.7 JVM Uptime Test ........................................................................................................................................................................ 420
11.1.8 JVM Garbage Collections Test ................................................................................................................................................... 424
11.1.9 JVM Memory Pool Garbage Collections Test ............................................................................................................................. 427
11.1.10 JMX Connection to JVM ............................................................................................................................................................. 431
11.1.11 JVM File Descriptors Test .......................................................................................................................................................... 433
11.2 THE ORACLE JDBC LAYER ...................................................................................................................................................................... 434
11.2.1 Oracle 9i Drivers Test ................................................................................................................................................................ 434
11.2.2 Oracle 9i Connection Cache Test ............................................................................................................................................... 435
11.2.3 Oracle 9i Transactions Test ........................................................................................................................................................ 436
11.3 THE ORACLE WEB MODULES LAYER ....................................................................................................................................................... 437
11.3.1 Oracle 9i Web Modules Test ....................................................................................................................................................... 438
11.4 THE ORACLE WEB CONTEXT LAYER ........................................................................................................................................................ 439
11.4.1 Oracle 9i Web Contexts Test ....................................................................................................................................................... 440
11.5 THE ORACLE J2EE LAYER ....................................................................................................................................................................... 441
11.5.1 Oracle 9i Jsps Test...................................................................................................................................................................... 441
11.5.2 Oracle 9i Servlets Test ................................................................................................................................................................ 443
MONITORING ORACLE 10G APPLICATION SERVERS .......................................................................................................................... 446
12.1 THE ORACLE J2EE LAYER ....................................................................................................................................................................... 447
12.1.1 Oracle Ejbs Test ......................................................................................................................................................................... 447
12.1.2 Oracle Jms Store Test ................................................................................................................................................................. 450
MONITORING ORACLE FORMS SERVERS ............................................................................................................................................... 452
13.1 THE FORMS PROCESSES LAYER ................................................................................................................................................................ 453
13.1.1 F9i Processes Test ...................................................................................................................................................................... 454
13.2 THE FORMS SERVER LAYER ..................................................................................................................................................................... 455
13.2.1 F9i Sessions Test......................................................................................................................................................................... 455
13.2.2 F9i Response Test ....................................................................................................................................................................... 457
13.3 THE FORMS USER LAYER ......................................................................................................................................................................... 458
13.3.1 F9i Users Test............................................................................................................................................................................. 458
MONITORING BORLAND ENTERPRISE SERVERS (BES) ...................................................................................................................... 461
14.1 THE AGENT LAYER .................................................................................................................................................................................. 462
14.1.1 Agent Statistics Test .................................................................................................................................................................... 462
14.2 THE PARTITION LAYER ............................................................................................................................................................................ 463
14.2.1 Partition Stat Test ....................................................................................................................................................................... 463

14.3 THE PARTITION SERVICES LAYER ............................................................................................................................................................ 464
14.3.1 CMP Test .................................................................................................................................................................................... 465
14.3.2 Ejb Cont Stat Test ....................................................................................................................................................................... 466
14.3.3 JDBC1 Test ................................................................................................................................................................................. 467
14.3.4 JDBC2 Test ................................................................................................................................................................................. 468
14.3.5 SFBeans Test .............................................................................................................................................................................. 469
14.3.6 Transactions Test ........................................................................................................................................................................ 471
MONITORING JBOSS APPLICATION SERVERS ....................................................................................................................................... 473
15.1 THE JVM LAYER ...................................................................................................................................................................................... 475
15.2 THE JB SERVER LAYER ............................................................................................................................................................................ 476
15.2.1 Jboss JVM Test ........................................................................................................................................................................... 476
15.2.2 Jboss Server Test ........................................................................................................................................................................ 478
15.2.3 Jboss Thread Pools Test ............................................................................................................................................................. 480
15.3 THE JB CONNECTION POOL LAYER .......................................................................................................................................................... 482
15.3.1 Jboss Connection Pools Test....................................................................................................................................................... 483
15.4 THE JB SERVLET LAYER .......................................................................................................................................................................... 485
15.4.1 Jboss Servlets Test ...................................................................................................................................................................... 486
15.5 THE JB EJB LAYER .................................................................................................................................................................................. 488
15.5.1 Jboss Ejbs Test............................................................................................................................................................................ 488
15.6 THE JB MQ LAYER .................................................................................................................................................................................. 490
15.6.1 Jboss MQ Queues Test ................................................................................................................................................................ 491
15.6.2 Jboss MQ Topics Test ................................................................................................................................................................. 494
MONITORING DOMINO APPLICATION SERVERS .................................................................................................................................. 497
16.1 ENABLING SNMP ON A DOMINO SERVER ................................................................................................................................................ 497
16.1.1 Enabling SNMP for a Domino Server on Solaris ........................................................................................................................ 498
16.1.2 Enabling SNMP for a Domino Server on Linux .......................................................................................................................... 500
16.1.3 Enabling SNMP for a Domino Server on AIX ............................................................................................................................. 502
16.1.4 Enabling SNMP for a Domino Server on Windows..................................................................................................................... 503
16.2 THE DOMINO SERVICE LAYER .................................................................................................................................................................. 508
16.2.1 Lotus Notes Web Server Test ...................................................................................................................................................... 508
16.2.2 Lotus Notes Replication Test....................................................................................................................................................... 511
CONCLUSION.................................................................................................................................................................................................... 515

Table of Figures
Figure 2.1: Layer model of the WebLogic Application server .................................................................................................................................. 4
Figure 2.2: The tests mapped to the Application Processes layer of the WebLogic server ........................................................................................ 4
Figure 2.3: The tests associated with the JVM layer.................................................................................................................................................. 9
Figure 2.4: The layers through which a Java transaction passes .............................................................................................................................. 31
Figure 2.5: The detailed diagnosis of the Slow transactions measure ...................................................................................................................... 43
Figure 2.6: The Method Level Breakup section in the At-A-Glance tab page ......................................................................................................... 44
Figure 2.7: The Component Level Breakup section in the At-A-Glance tab page ................................................................................................... 44
Figure 2.8: Query Details in the At-A-Glance tab page ........................................................................................................................................... 45
Figure 2.9: Detailed description of the query clicked on ......................................................................................................................................... 45
Figure 2.10: The Trace tab page displaying all invocations of the method chosen from the Method Level Breakup section .................................. 46
Figure 2.11: The Trace tab page displaying all methods invoked at the Java layer/sub-component chosen from the Component Level Breakup
section ............................................................................................................................................................................................................. 47
Figure 2.12: Queries displayed in the SQL/Error tab page ...................................................................................................................................... 48
Figure 2.13: Errors displayed in the SQL/Error tab page......................................................................................................................................... 48
Figure 2.14: The detailed diagnosis of the Error transactions measure .................................................................................................................... 49
Figure 2.15: Tests mapping to the WebLogic Service layer .................................................................................................................................... 82
Figure 2.16: The detailed diagnosis of the Max execution time measure ................................................................................................................ 93
Figure 2.17: Tests mapping to the WebLogic Database layer ................................................................................................................................ 142
Figure 2.18: Tests mapping to the WebLogic EJB layer ....................................................................................................................................... 158
Figure 2.19: The detailed diagnosis of the Cache hit ratio measure ....................................................................................................................... 165
Figure 2.20: The detailed diagnosis of the Threads timeout measure .................................................................................................................... 169
Figure 2.21: Layer model of the WebLogic Application server ............................................................................................................................. 180
Figure 2.22: The tests associated with the JVM layer ............................................................................................................................................ 181
Figure 2.23: Tests mapped to the WebLogic Service layer.................................................................................................................................... 182
Figure 2.24: Tests mapping to the WebLogic Database layer ................................................................................................................................ 182
Figure 2.25: Tests mapping to the WebLogic EJB layer ....................................................................................................................................... 183
Figure 3.1: Layer model for a WebSphere application server – 4/5.x.................................................................................................................... 185
Figure 3.2: Tests mapping to the WebSphere Service layer .................................................................................................................................. 185
Figure 3.3: Tests mapping to the WebSphere Database layer ................................................................................................................................ 197
Figure 3.4: Tests mapping to the WebSphere EJB layer ........................................................................................................................................ 202
Figure 3.5: Tests mapping to the WebSphere Web layer ....................................................................................................................................... 207
Figure 3.6: Layer model of the WebSphere Application server 6.0 (or above) ...................................................................................................... 241
Figure 3.7: The tests mapped to the JVM layer ..................................................................................................................................................... 242
Figure 3.8: The tests associated with the WAS Service layer ................................................................................................................................ 243
Figure 3.9: The test associated with the WAS Database layer ............................................................................................................................... 260
Figure 3.10: The tests associated with the WAS EJB layer ................................................................................................................................... 264
Figure 3.11: The tests associated with the WAS Web layer .................................................................................................................................. 278
Figure 4.1: Model of an iPlanet Application server showing the different layers monitored for the server ........................................................... 299
Figure 4.2: The NasSnmpTest that maps to the NAS Service layer of an iPlanet application server ..................................................................... 300
Figure 5.1: Layer model for a Coldfusion server ................................................................................................................................................... 303
Figure 5.2: The ColdfusionTest that maps to the CF Service layer of a Coldfusion application server ................................................................. 304
Figure 5.3: The ColdfusionTest that maps to the CF DB Access layer of a Coldfusion application server ........................................................... 308
Figure 6.1: Layer model for a SilverStream application server ............................................................................................................................. 310
Figure 6.2: Tests mapping to the Silver Stream Service layer ............................................................................................................................... 310
Figure 7.1: Layer model for a JRun application server .......................................................................................................................................... 314
Figure 7.2: The tests mapped to the JVM layer ..................................................................................................................................................... 314
Figure 7.3: Tests mapping to the JRUN Service layer ........................................................................................................................................... 315
Figure 8.1: Layer model of an Orion/Tomcat server ............................................................................................................................................. 321
Figure 8.2: Tests associated with the Java Application Server layer ..................................................................................................................... 322
Figure 9.1: The layer model of the Tomcat server ................................................................................................................................................. 324
Figure 9.2: Tests associated with JVM layer ......................................................................................................................................................... 326
Figure 9. 3: The detailed diagnosis of the CPU utilization of JVM measure ......................................................................................................... 349
Figure 9. 4: The detailed diagnosis of the Used memory measure ......................................................................................................................... 354
Figure 9.5: Tests associated with Web Server layer .............................................................................................................................................. 371
Figure 9.6: Tests associated with Java Application Server layer ........................................................................................................................... 377
Figure 10.1: The layer model of a SunONE application server ............................................................................................................................. 388
Figure 10.2: The tests mapped to the JVM layer ................................................................................................................................................... 388
Figure 10.3: Tests associated with the SunONE HTTP layer ................................................................................................................................ 389
Figure 10.4: Tests associated with the SunONE DB layer ..................................................................................................................................... 391
Figure 10.5: Test associated with the SunONE Transactions layer........................................................................................................................ 393
Figure 10.6: Tests associated with the SunONE EJB layer.................................................................................................................................... 394
Figure 11.1: The layer model of the Oracle 9i AS ................................................................................................................................................. 400

Figure 11.2: Tests associated with the Oracle JVM layer ...................................................................................................................................... 401
Figure 11.3: The tests associated with the Oracle==== JDBC layer ...................................................................................................................... 434
Figure 11.4: The tests associated with the Oracle Web Modules layer .................................................................................................................. 438
Figure 11.5: The tests associated with the Oracle Web Context layer ................................................................................................................... 440
Figure 11.6: The tests associated with the Oracle J2EE layer ................................................................................................................................ 441
Figure 12.1: The layer model of the Oracle 10G application server ...................................................................................................................... 446
Figure 12.2: The tests associated with the Oracle J2EE layer ................................................................................................................................ 447
Figure 13.1: The layer model of an Oracle Forms server ...................................................................................................................................... 452
Figure 13.2: The tests associated with the Forms Processes layer ......................................................................................................................... 453
Figure 13.3: Tests associated with the Forms Server layer .................................................................................................................................... 455
Figure 13.4: Tests associated with the Forms User layer ....................................................................................................................................... 458
Figure 14.1: The layer model of a Borland Enterprise server ................................................................................................................................ 461
Figure 14.2: The tests associated with the Agent layer .......................................................................................................................................... 462
Figure 14.3: The tests associated with the Partition layer ...................................................................................................................................... 463
Figure 14.4: The tests associated with the Partition Services layer ........................................................................................................................ 465
Figure 15.1: The layer model of a JBoss application server .................................................................................................................................. 474
Figure 15.2: The tests mapped to the JVM layer ................................................................................................................................................... 475
Figure 15.3: The tests associated with the JB Server layer .................................................................................................................................... 476
Figure 15.4: The test associated with the JB Connection Pool layer...................................................................................................................... 483
Figure 15.5: The test associated with the JB Servlet layer ..................................................................................................................................... 486
Figure 15.6: The test associated with the JB EJB layer ......................................................................................................................................... 488
Figure 15.7: The tests associated with the JB MQ layer ........................................................................................................................................ 491
Figure 16.1: The Add/Remove Programs option in the Control Panel window ..................................................................................................... 503
Figure 16.2: Select the Add/Remove Windows Components option ..................................................................................................................... 504
Figure 16.3: Selecting the Management and Monitoring Tools option .................................................................................................................. 504
Figure 16.4: Selecting the SNMP option ............................................................................................................................................................... 505
Figure 16.5: Providing the path to the Windows 2000 CD .................................................................................................................................... 505
Figure 16.6: Layer model of the Domino application server ................................................................................................................................. 507
Figure 16.7: The tests associated with the Domino Service Layer......................................................................................................................... 508

I n t r o d u c t i o n

Chapter

Introduction
To achieve scalability and performance, most Internet application deployments have evolved into
multi-tier infrastructures where the web server tier serves as the web front-end, the business logic is
executed on middleware application servers, and the backend storage and access is provided via
database servers. While multi-tier infrastructures offer a variety of scalability and extensibility
benefits, they are also more difficult to operate and manage. When a problem occurs (e.g., a
slowdown), an administrator often has difficulty in figuring out which application(s) in the multi-tier
infrastructure could be the cause of the problem - i.e., is it the network? Or the database? Or the
WebLogic server? Or the middleware? Or the web server? Comprehensive, routine monitoring of every
infrastructure application and network device is essential to be able to troubleshoot effectively when
problems occur.
The application server middleware that hosts and supports the business logic components is often the
most complex of the multi-tier infrastructure. To offer peak performance, an application server
provides a host of complex functions and features including database connection pooling, thread
pooling, database result caching, session management, bean caching and management etc. To ensure
that the application server is functioning effectively at all times, all of these functions have to be
monitored and tracked proactively and constantly.
eG Enterprise offers specialized monitoring models for each of the most popular application servers
such as WebLogic, WebSphere, ColdFusion, Oracle 9i/10G, etc. A plethora of metrics relating to the
health of the application servers can be monitored in real-time and alerts can be generated based on
user-defined thresholds or auto-computed baselines. These metrics enable administrators to quickly
and accurately determine server availability and responsiveness, resource usage at the host-level and
at the application server level, how well the application server processes requests, how quickly the
server completes transactions, overall server security, etc.
This document engages you in an elaborate discussion on how eG Enterprise monitors each of the
popular web application servers in the market.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Chapter

Monitoring WebLogic
Application Servers
BEA WebLogic Server is a fully-featured, standards-based application server providing the foundation
on which an enterprise can build reliable, scalable, and manageable applications. With its
comprehensive set of features, compliance with open standards, multi-tiered architecture, and support
for component-based development, WebLogic Server provides the underlying core functionality
necessary for the development and deployment of business-driven applications. Any issue with the
functioning of the WebLogic server, if not troubleshooted on time, can rupture the very core of these
business-critical applications, causing infrastructure downtime and huge revenue losses. This justifies
the need for continuously monitoring the external availability and internal operations of the WebLogic
server.
eG Enterprise provides two distinct models for monitoring WebLogic servers - the WebLogic model and
the WebLogic (6/7/8) model. As the names suggest, the WebLogic 6/7/8 model can be used to
monitor the WebLogic server version 6, 7, and 8, and the WebLogic model can be used for monitoring
WebLogic 9.0 (and above).
Regardless of the model used, the metrics obtained enable administrators to find answers to the
following persistent performance questions:

Server monitoring

JVM monitoring

Thread monitoring

Security monitoring



Is the WebLogic process running?



Is the memory usage of the server increasing over time?



Is the server's request processing rate unusually high?



Is the JVM heap size adequate?



Is the garbage collection tuned well or is the JVM spending too much
time in garbage collection?



Are the WebLogic servers execute queues adequately sized?



Are there too many threads waiting to be serviced, thereby causing
slow response time?



How many invalid login attempts have been made to the WebLogic
server?



Are these attempts recurring?

M o n i t o r i n g

W e b L o g i c

JMS monitoring

A p p l i c a t i o n

S e r v e r s



Are there many pending messages in the messaging server?



Is the message traffic unusually high?

Connector
monitoring



What is the usage pattern of connections in a connector pool?

Cluster monitoring



Are all the WebLogic servers in the cluster currently available?



Is the load being balanced across the cluster?

Transaction
monitoring



How many user transactions are happening?



Are there too many rollbacks occurring?

Servlet monitoring



Which servlet(s) are being extensively accessed?



What is the average invocation time for each servlet?



Are there adequate numbers of beans in a bean pool?



How many beans are in use? Are there any clients waiting for a bean?

EJB Pool monitoring

EJB
monitoring

Cache 

EJB Lock monitoring



What is the rate of EJB activations and passivations?



Is there contention for locks?



How many beans are locked?



How many attempts have been made to acquire a lock for each bean?

JDBC
Connection 
monitoring


JDBC call monitoring

Is the cache adequately sized or are there too many cache misses?

Are all the JDBC pools available?
Is each pool adequately sized?



What are the peak usage times and values?



How many connection leaks have occurred?



How many JDBC calls have been made?



What was average response time of those calls?



What are the queries that take a long time to execute?

The sections that will follow discuss each of these models in great detail.

2.1 Monitoring the WebLogic Server Ver. 9.0 (and above)
The special WebLogic monitoring model (see Figure 2.1) that eG Enterprise offers provides uses JMX
(Java Management extension), the new standard for managing java components, for monitoring the
WebLogic server 9.0 (and above). JMX allows users to instrument their applications and control or
monitor them using a management console. Using this mechanism, over a hundred critical metrics
relating to a WebLogic server instance can be monitored in real-time and alerts can be generated
based on user-defined thresholds or auto-computed baselines.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Figure 2.1: Layer model of the WebLogic Application server
The sections that will follow discuss the top 4 layers of Figure 2.1, and the metrics they report. In
addition, the Application Processes layer will also be touched upon, as it includes an additional test for
WebLogic servers called the Windows Service Resources test.
The remaining layers have been extensively dealt with in the Monitoring Unix and Window Servers
document.

2.1.1 The Application Processes Layer
The default Processes test mapped to this layer reports the availability and resource usage of the
processes that are critical to the functioning of the WebLogic server. For more details about the
Processes test, refer to the Monitoring Unix and Windows Servers document.
If the WebLogic server is operating on a Windows host, then, optionally, you can configure a Windows
Service Resources test for the server. This test reports the availability and resource usage of a
configured service.

Figure 2.2: The tests mapped to the Application Processes layer of the WebLogic server

M o n i t o r i n g

2.1.1.1

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Windows Service Resources Test

For a configured service, this test reports whether that service is up and running or not. In addition,
the test automatically determines the ID and name of the process that corresponds to the configured
service, and measures the CPU and memory usage of that process and the I/O load imposed by the
process. This test executes only on Windows hosts.
This test is disabled by default. Enable this test only if the WebLogic server is operating on a Windows host. To
enable the test, go to the ENABLE / DISABLE TESTS page using the menu sequence : Agents -> Tests ->
Enable/Disable, pick WebLogic as the Component type, Performance as the Test type, choose this test
from the DISABLED TESTS list, and click on the << button to move the test to the ENABLED TESTS list.
Finally, click the Update button.

Purpose

Reports whether the configured service is available or not, automatically determines
the ID and name of the process that corresponds to the configured service, and
measures the CPU and memory usage of that process and the I/O load imposed by
the process

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST – The IP address of the WebLogic server
3. PORT – The port number of the WebLogic server
4. SERVICENAME - Specify the exact name of the service to be monitored. For eg.,
to monitor the World Wide Web Publishing service, the SERVICENAME should
be: W3SVC. If your service name embeds white spaces, then specify the service
name within "double-quotes".

Outputs of the
test
Measurements
made by the
test

One set of results for the SERVICENAME configured

Measurement
Service availability:

Measurement
Unit
Percent

If the service exists on the target host
and is currently running, then this
measure will report the value 100. On
the other hand, if the service exists but
is not running, then this measure will
report the value 0. If the service does
not exist, then the test will report the
value Unknown.

Percent

A very high value could indicate that the
service is consuming excessive CPU
resources.

Indicates whether the
configured service is
available or not.

CPU utiization:

Interpretation

Indicates the
percentage of CPU
utilized by the process
that corresponds to the
configured
SERVICENAME

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Memory utilization:

S e r v e r s

Percent

A sudden increase in memory utilization
for a process may be indicative of
memory leaks in the application.

Number

An increasing trend in this measure is
indicative of a memory leak in the
service.

For
the
process
corresponding to the
specified
SERVICENAME,
this
value represents the
ratio of the resident set
size of the process to
the physical memory of
the
host
system,
expressed
as
a
percentage.
Handle count:
Indicates the number of
handles opened by the
process mapped to the
configured
SERVICENAME.
Number of threads:

Number

Indicates the number of
threads that are used
by the process that
corresponds to the
configured
SERVICENAME.
Virtual memory used:

Indicates the amount of
virtual memory that is
being used by the
process
that
corresponds
to
the
configured
SERVICENAME.
I/O data rate:

Kbytes/Sec

Indicates the rate at
which
the
process
mapped
to
the
configured
SERVICENAME
is
reading
and
writing
bytes in I/O operations.

This value counts all I/O activity
generated by a process and includes file,
network and device I/Os.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

I/O data operations:
Indicates the rate at
which
the
process
corresponding to the
specified SERVICENAME
is issuing read and write
data to file, network
and
device
I/O
operations.
I/O read data rate:

S e r v e r s

Operations/Se
c

Kbytes/Sec

Indicates the rate at
which the process that
corresponds
to
the
configured
SERVICE
NAME is reading data
from file, network and
device I/O operations.
I/O write data rate:

Kbytes/Sec

Indicates the rate at
which the process (that
corresponds
to
the
configured
SERVICENAME)
is
writing data to file,
network and device I/O
operations.
Page fault rate:

Faults/Sec

Indicates the total rate
at which page faults are
occurring
for
the
threads of the process
that
maps
to
the
configured
SERVICENAME.

A page fault occurs when a thread refers
to a virtual memory page that is not in
its working set in main memory. This
may not cause the page to be fetched
from disk if it is on the standby list and
hence already in main memory, or if it is
in use by another process with
whom the page is shared.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Memory working set:

S e r v e r s

The Working Set is the set of memory
pages touched recently by the threads in
the process. If free memory in the
computer is above a threshold, pages
are left in the Working Set of a process
even if they are not in use.
When free memory falls below a
threshold, pages are trimmed from
Working Sets. If they are needed they
will then be soft-faulted back into the
Working Set before leaving main
memory.

Indicates the current
size of the working set
of the process that
maps to the configured
SERVICENAME.

By tracking the working set of a process
over time, you can determine if the
application
has
a
memory
leak or not.

2.1.2 The JVM Layer
A Java virtual machine (JVM), an implementation of the Java Virtual Machine Specification, interprets
compiled java binary code for a computer's processor (or "hardware platform") so that it can perform
a Java program's instructions. The Java Virtual Machine Specification defines an abstract -- rather
than a real -- machine or processor. The Specification specifies an instruction set, a set of registers, a
stack, a garbage heap, and a method area.
The tests associated with the JVM layer of WebLogic enables administrators to perform the following
functions:



Assess the effectiveness of the garbage collection activity performed on the JVM heap



Monitor WebLogic thread usage



Evaluate the performance of the BEA JRockit JVM

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Figure 2.3: The tests associated with the JVM layer

2.1.2.1

WebLogic Test

This test monitors the performance of a WebLogic server by tracking the rate of requests processed by
the server, the number of requests waiting for processing, and the percentage of heap usage by the
server. While the rate of requests processed and the number of queued requests can be indicative of
performance problems with the WebLogic server, the percentage heap usage can be indicative of the
reason for the problem.
The heap size determines how often, and for how long garbage collection is performed by the Java
Virtual Machine (JVM) that hosts the WebLogic server. The Java heap is a repository for live objects,
dead objects, and free memory. When the JVM runs out of memory in the heap, all execution in the
JVM stops while a Garbage Collection (GC) algorithm goes through memory and frees space that is no
longer required by an application. This is an obvious performance hit because users accessing a
WebLogic server must wait while GC happens. No server-side work can be done during GC.
Consequently, the heap size must be tuned to minimize the amount of time that the JVM spends in
garbage collection, while at the same time maximizing the number of clients that the server can
handle at a given time. For Java 2 environments, it is recommended that the heap size be set to be as
possible without causing the host system to "swap" pages to disk (use the output of eG Enterprise's
SystemTest to gauge the amount of swapping being performed by the operating system).

Purpose

To measure statistics pertaining to a WebLogic application server

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST – The IP address of the WebLogic server
3. PORT – The port number of the WebLogic server
4. SNMPPORT – The port number on which the WebLogic server is exposing its
SNMP MIB (relevant to WebLogic server 5.1 only). For version 6.0 and above,
enter “none” in this text box.
5. SNMPVERSION – By default, the eG agent supports SNMP version 1. Accordingly,
the default selection in the SNMPVERSION list is v1. However, if a different SNMP
framework is in use in your environment, say SNMP v2 or v3, then select the
corresponding option from this list.
6. SNMPCOMMUNITY – The SNMP community string to be used with the SNMP
query to access the WebLogic server’s MIB (relevant to WebLogic server 5.1
only). For version 6.0 and above, enter “none” in this text box.
7. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
8. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
9. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
10. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

12. ENCRYPTTYPE – If the ENCRYPTFLAG is set to YES, then you will have to
mention the encryption type by selecting an option from the ENCRYPTTYPE list.
SNMP v3 supports the following encryption types:



DES – Data Encryption Standard



AES – Advanced Encryption Standard

13. ENCRYPTPASSWORD – Specify the encryption password here.
14. CONFIRM PASSWORD – Confirm the encryption password by retyping it here.
15. USER – The admin user name of the WebLogic server being monitored.
16. PASSWORD – The password of the specified admin user
17. CONFIRM PASSWORD – Confirm the password by retyping it here.
18. ENCRYPTPASS - If the specified password needs to be encrypted, set the
ENCRYPTPASS flag to YES. Otherwise, set it to NO. By default, the YES option will
be selected.

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS flag
is also set to No.
19. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.
20. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
21. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of the
server.
This
parameter
can
be
changed
to
a
value
of
http://:. In this case, the test connects
to the WebLogic admin server to collect metrics pertaining to the managed
server (specified by the HOST and PORT). The URL setting provides the
administrator with the flexibility of determining the WebLogic monitoring
configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed to
the admin server, and it is up and running.
22. VERSION - The VERSION textbox indicates the version of the Weblogic server to
be managed. The default value is "none", in which case the test auto-discovers
the weblogic version. If the value of this parameter is not "none", the test uses
the value provided (e.g., 7.0) as the weblogic version (i.e., it does not autodiscover the weblogic server version). This parameter has been added to
address cases when the eG agent is not able to discover the WebLogic server
version.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

23. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only. Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.
When monitoring a WebLogic server deployed on a Unix platform particularly, if
the USEWARFILE parameter is set to No, you have to make sure that the eG
agent install user is added to the WebLogic users group.
24. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's java
archive (Jar) file. If the USEWARFILE flag is set to No, then the weblogic.jar file
specified here is used to connect to the corresponding WebLogic server using
the T3 protocol. Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only.
25. TIMEOUT - Specify the duration (in seconds) within which the SNMP query
executed by this test should time out in the TIMEOUT text box. The default is 10
seconds.

Outputs of the
test
Measurements
made by the
test

One set of results for each WebLogic application server.

Measurement
Throughput:

Measurement
Unit

Interpretation

Reqs/Sec

A high request rate is an indicator of
server overload. By comparing the
request rates across application servers,
an operator can gauge the effectiveness
of load balancers (if any) that are in use.

Percent

When the heap used percent reaches
100%, the server will start garbage
collection
rather
than
processing
requests. Hence, a very high percentage
of heap usage (close to 100%) will
dramatically lower performance. In such
a case, consider increasing the heap size
to be used.

Requests queued:
Number of requests
currently waiting to be
processed by the
server.

Number

An increase in number of queued
requests can indicate a bottleneck on the
WebLogic server. One of the reasons for
this could be a bottleneck at the server
or due one or more of the applications
hosted on the server.

Total heap size:

Rate of requests
processed by the
WebLogic server.
Heap usage percent:
Percentage of heap
space currently in use
by the WebLogic server.

Current heap size of the
WebLogic server's Java
Virtual Machine

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Free heap size:

S e r v e r s

The currently unused
portion of the WebLogic
server's Java Virtual
Machine

2.1.2.2

WebLogic Threads Test

A WebLogic server (prior to version 9.x) may be configured with different execute queues. By default,
a WebLogic server is configured with one thread queue that is used for execution by all applications
running on a server instance. A common way of improving a WebLogic server’s performance is by
configuring multiple thread execute queues. For eg., a mission-critical application can be assigned to a
specific thread execute queue, thereby guaranteeing it a fixed number of execute threads. Other, less
critical applications may compete for threads in the default execute queue. While using different
thread execute queues can significantly improve performance, if the thread execute queues are not
properly configured or maintained, this could result in less than optimal performance. For eg., you
may find that while one thread queue has a number of idle threads, applications in another thread
execute queue could be waiting for execute threads to become available. In case of the WebLogic
server prior to version 9.x, the WebLogic Threads test monitors the different thread execute queues
configured for the server.
From WebLogic server 9.x onwards however, execute queues are replaced by ‘work managers’.
Therefore, while monitoring WebLogic server 9.x or above, the WebLogic Threads test will report one
set of metrics for every ‘work manager’ configured for the server. Also, the test will take an additional
ThreadPool descriptor, which will report the extent of usage of the thread pool.

Purpose

To report performance statistics pertaining to the thread execute queues of a
WebLogic server instance

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST – The IP address of the WebLogic server
3. PORT – The port number of the WebLogic server
4. USER – The admin user name of the WebLogic server being monitored.
5. PASSWORD – The password of the specified admin user
6. CONFIRM PASSWORD – Confirm the password by retyping it here.
7. ENCRYPTPASS - If the specified password needs to be encrypted, set the
ENCRYPTPASS flag to YES. Otherwise, set it to NO. By default, the YES option will
be selected.

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS flag
is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of the
server.
This
parameter
can
be
changed
to
a
value
of
http://:. In this case, the test connects
to the WebLogic admin server to collect metrics pertaining to the managed
server (specified by the HOST and PORT). The URL setting provides the
administrator with the flexibility of determining the WebLogic monitoring
configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed to
the admin server, and it is up and running.
11. VERSION - The VERSION textbox indicates the version of the Weblogic server
to be managed. The default value is "none", in which case the test autodiscovers the weblogic version. If the value of this parameter is not "none", the
test uses the value provided (e.g., 7.0) as the weblogic version (i.e., it does not
auto-discover the weblogic server version). This parameter has been added to
address cases when the eG agent is not able to discover the WebLogic server
version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only . Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

When monitoring a WebLogic server deployed on a Unix platform particularly, if
the USEWARFILE parameter is set to No, you have to make sure that the eG
agent install user is added to the WebLogic users group.
13. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's java
archive (Jar) file. If the USEWARFILE flag is set to No, then the weblogic.jar file
specified here is used to connect to the corresponding WebLogic server using
the T3 protocol. Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only.

Outputs of the
test
Measurements
made by the
test

One set of results for each thread execute queue of a WebLogic application server.

Measurement
Idle threads:

Measurement
Unit
Number

Indicates the number of
idle threads assigned to
a queue.

Thread utilization:

Interpretation
If the value of this measure is close to 0,
it indicates a probable delay in the
processing of subsequent requests.

In case of WebLogic 9.x or higher, this measure
will be available for the ThreadPool descriptor
only, and not the individual work managers.
Percent

Indicates the
percentage of threads
utilized in a queue

When this value becomes 100 %, it
indicates a heavy load on the server and
that it cannot process further requests
until a few threads become idle.
Typically, this value should be less than
90%.

In case of WebLogic 9.x or higher, this measure
will be available for the ThreadPool descriptor
only, and not the individual work managers.
Pending requests:

Number

A high value of this measure can result
in significant request processing delays.

Reqs/sec

While a high value of this measure is
indicative of the good health of the
server, a low value indicates a
processing bottleneck.

Indicates the number of
requests waiting in the
queue
Requests:
Indicates the number of
requests that are
processed by the server
per second

2.1.2.3

WebLogic Rockit JVM Test

This test exposes runtime data about the JRockit Virtual Machine (VM) that is running the current
WebLogic Server instance.
The WebLogic Rockit JVM test will work only if the following conditions are fulfilled:



The Weblogic Server must be launched on the JRockit JVM



The managementapi.jar should be on the Weblogic server's startup classpath

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Purpose

To report runtime data about the JRockit Virtual Machine (VM) that is running the
current WebLogic Server instance

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS flag
is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of the
server.
This
parameter
can
be
changed
to
a
value
of
http://:. In this case, the test connects
to the WebLogic admin server to collect metrics pertaining to the managed
server (specified by the HOST and PORT). The URL setting provides the
administrator with the flexibility of determining the WebLogic monitoring
configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed to
the admin server, and it is up and running.
11. VERSION - The VERSION textbox indicates the version of the Weblogic server to
be managed. The default value is "none", in which case the test auto-discovers
the weblogic version. If the value of this parameter is not "none", the test uses
the value provided (e.g., 7.0) as the weblogic version (i.e., it does not autodiscover the weblogic server version). This parameter has been added to
address cases when the eG agent is not able to discover the WebLogic server
version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only . Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the
test

One set of results for every WebLogic server being monitored.

Measurement
Total heap:

Measurement
Unit

Interpretation

Indicates the amount of
memory
currently
allocated to the Virtual
Machine's Java heap.
Used heap:

If the value of this measure increases
consistently, it is indicative of heavy load
on the Virtual Machine.

A very low value of this measure is a
cause of concern, as it indicates a heavy
utilization of the JVM heap. Consider
increasing the JVM heap size under such
circumstances.

Indicates the amount of
Java heap memory that
is currently being used
by the Virtual Machine.
Free heap:
Indicates the amount
of Java heap memory
that is currently free in
the Virtual Machine.
Total nursery:

Indicates the amount of
memory
that
is
currently allocated to
the nursery.
GC count:

Number

Indicates the number of
garbage collection runs
that
have
occurred
since
the
Virtual
Machine was started.
GC time:

Secs

Indicates the time that
the Virtual Machine has
spent on all garbage
collection runs since the
VM was started.

If GC has run too many times during a
short interval, it indicates that the JVM is
in dire need of free heap for normal
functioning. Moreover, frequent GC
executions could cause application
performance to deteriorate. In order to
avoid this, it is recommended that you
increase the heap size or alter the GC
frequency.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Total load:
Indicates
percentage
the Virtual
placing
processors
computer.

S e r v e r s

Percent
the
of load that
Machine is
on
all
in the host

Percent heap used:

Percent

Indicates
the
percentage of the total
Java heap memory that
is currently being used
by the Virtual Machine.

2.1.2.4

WebLogic Work Managers Test

The WebLogic Server allows you to configure how your application prioitizes the execution of its work
based on rules you define and by monitoring actual runtime performance. You define the rules and
constraints for your application by defining a Work Manager and applying it either globally to WebLogic
Server domain or to a specific application component.
This test monitors the requests to applications, and helps analyze how the work manager mapped to
each application is managing the requests. By closely observing the variations to the measures
reported by this test, you can quickly identify current/potential application slowdowns, and figure out
whether changes in the corresponding work manager specification can improve application
performance.

Purpose

Monitors the requests to applications, and helps analyze how the work manager
mapped to each application is managing the requests

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS flag
is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of the
server.
This
parameter
can
be
changed
to
a
value
of
http://:. In this case, the test connects
to the WebLogic admin server to collect metrics pertaining to the managed
server (specified by the HOST and PORT). The URL setting provides the
administrator with the flexibility of determining the WebLogic monitoring
configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed to
the admin server, and it is up and running.
11. VERSION - The VERSION textbox indicates the version of the Weblogic server to
be managed. The default value is "none", in which case the test auto-discovers
the weblogic version. If the value of this parameter is not "none", the test uses
the value provided (e.g., 7.0) as the weblogic version (i.e., it does not autodiscover the weblogic server version). This parameter has been added to
address cases when the eG agent is not able to discover the WebLogic server
version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only . Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

13. When monitoring a WebLogic server deployed on a Unix platform particularly, if
the USEWARFILE parameter is set to No, you have to make sure that the eG
agent install user is added to the WebLogic users group.
14. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's java
archive (Jar) file. If the USEWARFILE flag is set to No, then the weblogic.jar file
specified here is used to connect to the corresponding WebLogic server using
the T3 protocol. Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only.

Outputs of the
test
Measurements
made by the
test

One set of results for every work manager on the WebLogic server being monitored.

Measurement
Completed requests:

Measurement
Unit
Number

Indicates the number of
requests
that
were
successfully serviced by
the
work
manager
mapped
to
this
application.

Interpretation

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Pending requests:

S e r v e r s

Number

Indicates the number of
requests to this
application that are
waiting in the queue.

A large number of pending requests to
an
application
could
indicate
a
bottleneck in the request processing
ability of that application. If too many
applications on the server support longwinding
request
queues,
it
can
ultimately overload the server, and
eventually choke its performance. It is
therefore essential to quickly isolate
those
applications
that
could
be
experiencing
issues
with
request
processing, and then initiate the relevant
remedial action on them. Comparing the
value of this measure across applications
will enable you to accurately identify
which application has the maximum
number of pending requests. Once the
application is spotted, you may want to
observe the variations in the pending
requests count over time for that
application. If you find that the value of
this measure keeps increasing with time
for that application, further investigation
may be necessary to determine the
reasons for the same. One of the
possible reasons for this could be the
lack of sufficient threads. Incoming
requests to an application cannot be
processed if adequate threads are
unavailable; such requests will hence be
in queue until such time that the server
allocates
more
threads
to
the
application.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

As already stated, the WebLogic server
prioritizes work and allocates threads to
an application based on the rules and
constraints defined within the work
manager that is either defined globally
or
mapped
specifically
to
that
application. Therefore, in the event of a
slow down in the request processing rate
of an application, you can consider finetuning its associated work manager
definition, so as to ensure the
uninterrupted processing of requests. A
typical work manager definition should
include one request class and one/more
thread constraints. A request class
expresses a scheduling guideline that
WebLogic Server uses to allocate
threads to requests. Request classes
help ensure that high priority work is
scheduled before less important work,
even if the high priority work is
submitted after the lower priority work.
A work manager can specify any one of
the below-mentioned request classes:



Fair share request class: This
specifies the average thread-use
time required to process requests.
For example, assume that WebLogic
Server is running two modules. The
Work Manager for ModuleA specifies
a fair-share-request-class of 80 and
the Work Manager for ModuleB
specifies a fair-share-request-class
of 20. During a period of sufficient
demand, with a steady stream of
requests for each module such that
the number requests exceed the
number of threads, WebLogic Server
will allocate 80% and 20% of the
thread-usage time to ModuleA and
ModuleB, respectively.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



Response time request class: This
type of request class specifies a
response time goal in milliseconds.
Response time goals are not applied
to individual requests. Instead,
WebLogic
Server
computes
a
tolerable waiting time for requests
with that class by subtracting the
observed average thread use time
from the response time goal, and
schedules requests so that the
average wait for requests with the
class is proportional to its tolerable
waiting time.



Context request class: This type of
request class assigns request classes
to requests based on context
information, such as the current user
or the current user’s group.

A constraint defines minimum and
maximum numbers of threads allocated
to execute requests and the total
number of requests that can be queued
or executing before WebLogic Server
begins rejecting requests. You can define
the following types of constraints:



max-threads-constraint—This
constraint limits the
concurrent
threads

number of
executing

requests from the constrained work
set. The default is unlimited. For
example, consider a constraint
defined with maximum threads of 10
and shared by 3 entry points. The
scheduling logic ensures that not
more than 10 threads are executing
requests from the three entry points
combined.



min-threads-constraint—This
constraint guarantees a number of
threads the server will allocate to
affected requests to avoid deadlocks.
The default is zero.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

A min-threads-constraint value
of one is useful, for example, for
a replication update request,
which is called synchronously
from a peer.



capacity—This constraint causes
the server to reject requests
only when it has reached its
capacity. The default is -1. Note
that the capacity includes all
requests, queued or executing,
from the constrained work set.
Work is rejected either when an
individual capacity threshold is
exceeded or if the global
capacity
is
exceeded.
This
constraint is independent of the
global queue threshold.

Stuck threads:

Number

Indicates the number of
threads
that
are
considered to be stuck
on the basis of any
thread constraints.

WebLogic Server diagnoses a thread as
stuck if it is continually working (not
idle) for a set period of time. You can
tune
a
server's
thread
detection
behavior by changing the length of time
before a thread is diagnosed as stuck,
and by changing the frequency with
which the server checks for stuck
threads.
In response to stuck threads, you can
define a Stuck Thread Work Manager
component that can shut down the Work
Manager, move the application into
admin mode, or mark the server
instance as failed.

2.1.2.5

WebLogic Thread Pools Test

Starting from WebLogic server release 9.0, every server instance uses a self-tuned thread-pool. All
requests, whether related to system administration or application activity—are processed by this
single thread pool. The self-tuning thread pool would also adjust its pool size automatically based on
the throughput history that WLS gathers every 2 seconds and based on queue size.
This test monitors how the self-tuning thread pool is being used, and in the process reports whether
there are adequate idle threads in the pool to handle additional workload that may be imposed on the
WebLogic server. The test also turns the spot light on the request (if any) that is hogging threads, and
enables you to quickly capture a sudden/consistent increase in queue size, which in turn might impact
the pool size.

Purpose

Monitors how the self-tuning thread pool is being used, and in the process reports
25

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

whether there are adequate idle threads in the pool to handle additional workload
that may be imposed on the WebLogic server

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS flag
is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of the
server.
This
parameter
can
be
changed
to
a
value
of
http://:. In this case, the test connects
to the WebLogic admin server to collect metrics pertaining to the managed
server (specified by the HOST and PORT). The URL setting provides the
administrator with the flexibility of determining the WebLogic monitoring
configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed to
the admin server, and it is up and running.
11. VERSION - The VERSION textbox indicates the version of the Weblogic server to
be managed. The default value is "none", in which case the test auto-discovers
the weblogic version. If the value of this parameter is not "none", the test uses
the value provided (e.g., 7.0) as the weblogic version (i.e., it does not autodiscover the weblogic server version). This parameter has been added to
address cases when the eG agent is not able to discover the WebLogic server
version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only. Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the
test

One set of results for the self-tuning thread pool on the WebLogic server being
monitored.

Measurement
Active threads:

Measurement
Unit
Number

Indicates
the
total
number
of
active
threads in this pool.

Interpretation
A high value for this measure is
indicative of a high load on the
applications deployed on the WebLogic
server.
This measure is also useful for
determining usage trends. For example,
it can show the time of day and the day
of the week in which you usually reach
peak thread count. In addition, the
creation of too many threads can result
in out of memory errors or thrashing. By
watching this metric, you can reduce
excessive memory consumption before
it’s too late.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Hogging threads:

S e r v e r s

Number

Indicates the number of
threads that are
currently hogged by a
request.

Ideally, the value of this measure should
be low. A very high value indicates that
a request is using up too many threads.
Hogging threads will either be declared
as stuck after the configured timeout or
will return to the pool before that. The
self-tuning mechanism will backfill if
necessary.
WebLogic Server automatically detects
when a thread in a pool becomes
“stuck.” Because a stuck thread cannot
complete its current work or accept new
work, the server logs a message each
time it diagnoses a stuck thread.
WebLogic Server diagnoses a thread as
stuck if it is continually working (not
idle) for a set period of time. You can
tune
a
server’s
thread
detection
behavior by changing the length of time
before a thread is diagnosed as stuck,
and by changing the frequency with
which the server checks for stuck
threads. Although you can change the
criteria WebLogic Server uses to
determine whether a thread is stuck,
you cannot change the default behavior
of setting the “warning” and “critical”
health states when all threads in a
particular execute queue become stuck.

Idle threads:

Number

A high value is desired for this measure.

Number

This measure comprises of both the
internal system requests and requests
made by the user.

Indicates the number of
idle threads (i.e., the
threads that are ready
to process a new job as
and when it arrives) in
the pool.
Queue length:
Indicates the number of
pending requests in the
priority queue.

A low value is desired for this measure.
A high value or a sudden increase in this
value may indicate a sudden slowdown
in responsiveness or a performance
bottleneck.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Standby threads:

S e r v e r s

Number

Threads that are not needed to handle
the present work load are designated as
standby and are added to the standby
pool. These threads are activated when
more threads are needed.

Number

The queue monitors throughput over
time and based on history, determines
whether to adjust the thread count or
not. For example, if historical throughput
statistics indicate that a higher thread
count increased throughput, the server
increases it. Similarly, if statistics
indicate that fewer threads did not
reduce throughput, the count will be
reduced.

Indicates the number of
threads that are
currently in the standby
pool.
Throughput:
Indicates the number of
requests in the priority
queue that are
completed.

Total threads:

Number

Indicates
the
total
number of threads in
this pool.

2.1.2.6

Tests Disabled by Default for the JVM Layer

The tests discussed above are enabled by default for a WebLogic server. Besides these tests, the eG
agent can be optionally configured to execute a few other tests on the WebLogic server’s JVM so as to
report critical statistics related to the Java transactions, classes loaded/unloaded, threads used, CPU
and memory resources used, garbage collection activity, uptime of the JVM, etc. These additional tests
are disabled by default for the WebLogic server. To enable one/more tests, go to the ENABLE / DISABLE
TESTS page using the menu sequence : Agents -> Tests -> Enable/Disable, pick WebLogic as the
Component type, Performance as the Test type, choose the tests from the DISABLED TESTS list, and click on
the >> button to move the tests to the ENABLED TESTS list. Finally, click the Update button.
These JVM tests have been discussed below.
When a user initiates a transaction to a Java-based web application, the transaction typically travels
via many Java components before completing execution and sending out a response to the user.
Figure 2.4 reveals some of the Java components that a web transaction/web request visits during its
journey.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Figure 2.4: The layers through which a Java transaction passes
The key Java components depicted by Figure 2.4 have been briefly described below:



Filter: A filter is a program that runs on the server before the servlet or JSP page with which
it is associated. All filters must implement javax.servlet.Filter. This interface comprises three
methods: init, doFilter, and destroy.



Servlet: A servlet acts as an intermediary between the client and the server. As servlet
modules run on the server, they can receive and respond to requests made by the client. If a
servlet is designed to handle HTTP requests, it is called an HTTP Servlet.



JSP: Java Server Pages are an extension to the Java servlet technology. A JSP is translated
into Java servlet before being run, and it processes HTTP requests and generates responses
like any servlet. Translation occurs the first time the application is run.



Struts: The Struts Framework is a standard for developing well-architected Web applications.
Based on the Model-View-Controller (MVC) design paradigm, it distinctly separates all three
levels (Model, View, and Control).

A delay experienced by any of the aforesaid Java components can adversely impact the total response
time of the transaction, thereby scarring the user experience with the web application. In addition,
delays in JDBC connectivity and slowdowns in SQL query executions (if the application interacts with a
database), bottlenecks in delivery of mails via the Java Mail API (if used), and any slow method calls,
can also cause insufferable damage to the 'user-perceived' health of a web application.
The challenge here for administrators is to not just isolate the slow transactions, but to also accurately
identify where the transaction slowed down and why - is it owing to inefficent JSPs? poorly written
servlets or struts? poor or the lack of any JDBC connectivity to the database? long running queries?
inefficient API calls? or delays in accessing the POJO methods? The eG JTM Monitor provides
administrators with answers to these questions!
With the help of the Java Transactions test, the eG JTM Monitor traces the route a configured web
transaction takes, and captures live the total responsiveness of the transaction and the response time
of each Java component it visits en route. This way, the solution proactively detects transaction
slowdowns, and also precisely points you to the Java components causing it - is it the Filters? JSPs?
31

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Servlets? Struts? JDBC? SQL query? Java Mail API? or the POJO? In addition to revealing where (i.e.,
at which Java component) a transaction slowed down, the solution also provides the following
intelligent insights, on demand, making root-cause identification and resolution easier:



A look at the methods that took too long to execute, thus leading you to those methods that
may have contributed to the slowdown;



Single-click access to each invocation of a chosen method, which provides pointers to when
and where a method spent longer than desired;



A quick glance at SQL queries and Java errors that may have impacted the responsiveness of
the transaction;

Using these interesting pointers provided by the eG JTM Monitor, administrators can diagnose the rootcause of transaction slowdowns within minutes, rapidly plug the holes, and thus ensure that their
critical web applications perform at peak capacity at all times!
Before attempting to monitor Java transactions using the eG JTM Monitor, the following configurations
will have to be performed:
1. In the \lib directory (on Windows; on Unix, this will be /opt/egurkha/lib) of the eG
agent, you will find the following files:



eg_jtm.jar



aspectjrt.jar



aspectjweaver.jar



jtmConn.props



jtmLogging.props



jtmOther.props

2. Login to the system hosting the Java application to be monitored.
3. If the eG agent will be 'remotely monitoring' the target Java application (i.e., if the Java
application is to be monitored in an 'agentless manner'), then, copy all the files mentioned above
from the \lib directory (on Windows; on Unix, this will be /opt/egurkha/lib) of the eG
agent to any location on the Java application host.
4. Then, proceed to edit the start-up script of the Java application being monitored, and append the
following lines to it:
set JTM_HOME=<>
"-javaagent:%JTM_HOME%\aspectjweaver.jar"
"-DEG_JTM_HOME=%JTM_HOME%"

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Then, every time the eG agent runs the Java Transactions test, the agent will poll the eG JTM Monitor
(on the target application) for the required metrics, extract the same from the application's
memory, and report them to the eG manager.
5. Next, edit the jtmConn.props file. You will find the following lines in the file:
#Contains the connection properties of eGurkha Java Transaction Monitor
JTM_Port=13631
Designated_Agent=
By default, the JTM_Port parameter is set to 13631. If the Java application being monitored listens
on a different JTM port, then specify the same here. In this case, when managing a Java Application
using the eG administrative interface, specify the JTM_Port that you set in the jtmConn.props file as
the Port of the Java application.
Also, against the Designated_Agent parameter, specify the IP address of the eG agent which will poll
the eG JTM Monitor for metrics. If no IP address is provided here, then the eG JTM Monitor will treat
the host from which the very first 'measure request' comes in as the Designated_Agent.

Note:
In case a specific Designated_Agent is not provided, and the eG JTM Monitor treats the host from
which the very first 'measure request' comes in as the Designated_Agent, then if such a
Designated_Agent is stopped or uninstalled for any reason, the eG JTM Monitor will wait for a
maximum of 10 measure periods for that 'deemed' Designated_Agent to request for metrics. If
no requests come in for 10 consecutive measure periods, then the eG JTM Monitor will begin
responding to 'measure requests' coming in from any other eG agent.

6. Finally, save the jtmConn.props file.
Then, proceed to configure the Java Transactions test as discussed below.

Purpose

Traces the route a configured web transaction takes, and captures live the total
responsiveness of the transaction and the response time of each component it visits
en route. This way, the solution proactively detects transaction slowdowns, and also
precisely points you to the Java component causing it - is it the Filters? JSPs?
Servlets? Struts? JDBC? SQL query? Java Mail API? or the POJO?

Target of the
test

A Java application/web application server

Agent
deploying the
test

An internal/remote agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT - The port number at which the specified HOST listens; if Java Transaction
Monitoring is enabled for the target Java application, then the JTM PORT has to
be specified here
4. JTM PORT – Specify the port number configured as the JTM_Port in the
jtmConn.props file described in the procedure outlined above.
5. URL PATTERNS - Provide a comma-separated list of the URL patterns of web
requests/transactions to be monitored. The format of your specification should
be as follows: :. For instance,
your specification can be: login:*log*,ALL:*,pay:*pay*
6. FILTERED URL PATTERNS - Provide a comma-separated list of the URL patterns
of transactions/web requests to be excluded from the monitoring scope of this
test. For example, *blog*,*paycheque*
7. SLOW URL THRESHOLD - The Slow transactions measure of this test will report
the number of transactions (of the configured patterns) for which the response
time is higher than the value (in seconds) specified here.
8. METHOD EXEC CUTOFF - The detailed diagnosis of the Slow transactions
measure allows you to drill down to a URL tree, where the methods invoked by a
chosen transaction are listed in the descending order of their execution time. By
configuring an execution duration (in seconds) here, you can have the URL Tree
list only those methods that have been executing for a duration greater the
specified value. For instance, if you specify 5 here, the URL tree for a
transaction will list only those methods that have been executing for over 5
seconds, thus shedding light on the slow method calls alone.
9. MAX SLOW URLS PER TEST PERIOD - Specify the number of top-n transactions
(of a configured pattern) that should be listed in the detailed diagnosis of the
Slow transactions measure, every time the test runs. By default, this is set to
10, indicating that the detailed diagnosis of the Slow transactions measure will
by default list the top-10 transactions, arranged in the descending order of their
response times.
10. MAX ERROR URLS PER TEST PERIOD - Specify the number of top-n transactions
(of a configured pattern) that should be listed in the detailed diagnosis of the
Error transactions measure, every time the test runs. By default, this is set to
10, indicating that the detailed diagnosis of the Error transactions measure will
by default list the top-10 transactions, in terms of the number of errors they
encountered.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

11. DD FREQUENCY - Refers to the frequency with which detailed
diagnosis measures are to be generated for this test. The default is 1:1. This
indicates that, by default, detailed measures will be generated every time this
test runs, and also every time the test detects a problem. You can modify this
frequency, if you so desire. Also, if you intend to disable the detailed diagnosis
capability for this test, you can do so by specifying none against DD
FREQUENCY.
12. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for each configured URL pattern

Measurement
Unit

Measurement
Total transactions:

Interpretation

Number

Indicates the total number of
transactions of this pattern that
the target application handled
during the last measurement
period.
Avg. response time:

Secs

Indicates the average time taken
by the transactions of this
pattern to complete execution.

Compare the value of this
measure
across
patterns
to
isolate the type of transactions
that were taking too long to
execute.
You can then take a look at the
values of the other measures to
figure out where the transaction
is spending too much time.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Slow transactions:

Number

Indicates the number of
transactions of this pattern that
were slow during the last
measurement period.

This measure will report the
number of transactions with a
response time higher than the
configured
SLOW
URL
THRESHOLD.
A high value is a cause for
concern, as too many slow
transactions to an application can
significantly damage the user
experience with that application.
Use the detailed diagnosis of this
measure
to
know
which
transactions are slow.

Slow transactions response
time:

Secs

Indicates the average time taken
by the slow transactions of this
pattern to execute.
Error transactions:

Number

Indicates the number of
transactions of this pattern that
experienced errors during the
last measurement period.

A high value is a cause for
concern, as too many error-prone
transactions to an application can
significantly damage the user
experience with that application.
Use the detailed diagnosis of this
measure to isolate the error
transactions.

Error transactions response
time:

Secs

Indicates the average duration
for which the transactions of this
pattern were processed before
an error condition was detected.
Filters:

Number

Indicates the number of filters
that were accessed by the
transactions of this pattern
during the last measurement
period.

A filter is a program that runs on
the server before the servlet or
JSP page with which it is
associated.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Filters response time:

Secs

Indicates the average time spent
by the transactions of this
pattern at the Filters layer.

Typically, the init, doFilter, and
destroy methods are called at
the Filters layer. Issues in these
method invocations can increase
the time spent by a transaction in
the Filters Java component.
Compare the value of this
measure
across
patterns
to
identify the transaction pattern
that spent the maximum time
with the Filters component.
If one/more transactions of a
pattern are found to be slow,
then, you can compare the value
of this measure with the other
response time values reported by
this test to determine where the
slowdown actually occurred - in
the filters, in JSPs, in servlets, in
struts, in exception handling,
when
executing
JDBC/SQL
queries, when sending Java mails,
or when accessing POJOs.

JSPs accessed:

Number

Indicates the number of JSPs
accessed by the transactions of
this pattern during the last
measurement period.
JSPs response time:

Secs

Indicates the average time spent
by the transactions of this
pattern at the JSP layer.

Compare the value of this
measure
across
patterns
to
identify the transaction pattern
that spent the maximum time in
JSPs.
If one/more transactions of a
pattern are found to be slow,
then, you can compare the value
of this measure with the other
response time values reported by
this test to determine where the
slowdown actually occurred - in
the filters, in JSPs, in servlets, in
struts, in exception handling,
when
executing
JDBC/SQL
queries, when sending Java mails,
or when accessing POJOs..

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

HTTP Servlets Accessed:

Number

Indicates the number of HTTP
servlets that were accessed by
the transactions of this pattern
during the last measurement
period.
HTTP servlets response time:

Secs

Indicates the average time taken
by the HTTP servlets for
processing the HTTP requests of
this pattern.

Badly written servlets can take
too long to execute, and can
hence
obstruct
the
smooth
execution
of
the
dependent
transactions.
By comparing the value of this
measure across patterns, you can
figure out which transaction
pattern is spending the maximum
time in Servlets.
If one/more transactions of a
pattern are found to be slow,
then, you can compare the value
of this measure with the other
response time values reported by
this test to determine where the
slowdown actually occurred - in
the filters, in JSPs, in servlets, in
struts, in exception handling,
when
executing
JDBC/SQL
queries, when sending Java mails,
or when accessing POJOs.

Generic servlets accessed:

Number

Indicates the number of generic
(non-HTTP) servlets that were
accessed by the transactions of
this pattern during the last
measurement period.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Generic servlets response
time:

Secs

Indicates the average time taken
by the generic (non-HTTP)
servlets for processing
transactions of this pattern.

JDBC queries:

Number

Indicates the number of JDBC
statements that were executed
by the transactions of this
pattern during the last
measurement period.

The methods captured by the eG
JTM Monitor from the Java class for
the JDBC sub-component include:

Commit(),
rollback(..),
close(),GetResultSet(),
executeBatch(), cancel(),
connect(String,
Properties),
getConnection(..),getPool
edConnection(..)

JDBC response time:

Secs

Indicates the average time taken
by the transactions of this
pattern to execute JDBC
statements.

By comparing the value of this
measure across patterns, you can
figure out which transaction
pattern is taking the most time to
execute JDBC queries.
If one/more transactions of a
pattern are found to be slow,
then, you can compare the value
of this measure with the other
response time values reported by
this test to determine where the
slowdown actually occurred - in
the filters, in JSPs, in servlets, in
struts, in exception handling,
when
executing
JDBC/SQL
queries, when sending Java mails,
or when accessing POJOs.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

SQL statements executed:

Number

Indicates the number of SQL
queries executed by the
transactions of this pattern
during the last measurement
period.
SQL statement time avg.:

Secs

Indicates the average time taken
by the transactions of this
pattern to execute SQL queries.

Inefficient queries can take too
long to execute on the database,
thereby significantly delaying the
responsiveness of the dependent
transactions. To know which
transactions have been most
impacted
by
such
queries,
compare the value of this
measure across the transaction
patterns.
If one/more transactions of a
pattern are found to be slow,
then, you can compare the value
of this measure with the other
response time values reported by
this test to determine where the
slowdown actually occurred - at
the filters layer, JSPs layer,
servlets layer, struts layer, in
exception
handling,
when
executing
JDBC/SQL
queries,
when sending Java mails, or
when accessing POJOs.

Exceptions seen:

Number

Ideally, the value of this measure
should be 0.

Secs

If one/more transactions of a
pattern are found to be slow,
then, you can compare the value
of this measure with the other
response time values reported by
this test to determine where the
slowdown actually occurred - at
the filters layer, JSPs layer,
servlets layer, struts layer, in
exception
handling,
when
executing
JDBC/SQL
queries,
when sending Java mails, or
when accessing POJOs.

Indicates the number of
exceptions encountered by the
transactions of this pattern
during the last measurement
period.
Exceptions response time:
Indicates the average time which
the transactions of this pattern
spent in handling exceptions.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Struts accessed:

Number

The
Struts framework is a
standard for developing wellarchitected Web applications.

Secs

If you compare the value of this
measure across patterns, you can
figure out which transaction
pattern spent the maximum time
in Struts.

Indicates the number of struts
accessed by the transactions of
this pattern during the last
meaurement period.
Struts response time:
Indicates the average time spent
by the transactions of this
pattern at the Struts layer.

If one/more transactions of a
pattern are found to be slow,
then, you can compare the value
of this measure with the other
response time values reported by
this test to determine where the
slowdown actually occurred - in
the filters, in JSPs, in servlets, in
struts, in exception handling,
when
executing
JDBC/SQL
queries, when sending Java mails,
or when accessing POJOs.
Java mails:

Number

The eG JTM Monitor captures any
mail that has been sent from the
monitored application using Java
Mail API. Mails sent using other
APIs are ignored by the eG JTM
Monitor.

Secs

If one/more transactions of a
pattern are found to be slow,
then, you can compare the value
of this measure with the other
response time values reported by
this test to determine where the
slowdown actually occurred - in
the filters, in JSPs, in servlets, in
struts, in exception handling,
when
executing
JDBC/SQL
queries, when sending Java mails,
or when accessing POJOs.

Indicates the number of mails
sent by the transactions of this
pattern during the last
measurement period, using the
Java mail API.
Java mail API time:
Indicates the average time taken
by the transactions of this
pattern to send mails using the
Java mail API.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

POJOs:

Number

Indicates the number of
transactions of this pattern that
accessed POJOs during the last
measurement period.

Plain Old Java Object (POJO)
refers to a 'generic' method in
JAVA Language. All methods that
are not covered by any of the
Java components (eg., JSPs,
Struts,
Servlets,
Filters,
Exceptions,
Queries,
etc.)
discussed
above
will
be
automatically
included
under
POJO.
When reporting the number of
POJO methods, the eG agent will
consider only those methods with
a response time value that is
higher than the threshold limit
configured against the METHOD
EXEC CUTOFF parameter.

POJO avg. access time:

Secs

Indicates the average time taken
by the transactions of this
pattern to access POJOs.

If one/more transactions of a
pattern are found to be slow,
then, you can compare the value
of this measure with the other
response time values reported by
this test to determine where the
slowdown actually occurred - in
the filters, in JSPs, in servlets, in
struts, in exception handling,
when
executing
JDBC/SQL
queries, when sending Java mails,
or when accessing POJOs.

The detailed diagnosis of the Slow transactions measure lists the top-10 (by default) transactions of a
configured pattern that have violated the response time threshold set using the SLOW URL
THRESHOLD parameter of this test. Against each transaction, the date/time at which the transaction
was initiated/requested will be displayed. Besides the request date/time, the remote host from which
the transaction request was received and the total response time of the transaction will also be
reported. This response time is the sum total of the response times of each of the top methods (in
terms of time taken for execution) invoked by that transaction. To compute this sum total, the test
considers only those methods with a response time value that is higher than the threshold limit
configured against the METHOD EXEC CUTOFF parameter.
In the detailed diagnosis, the transactions will typically be arranged in the descending order of the
total response time; this way, you would be able to easily spot the slowest transaction. To know what
caused the transaction to be slow, you can take a look at the SUBCOMPONENT DETAILS column of the
detailed diagnosis. Here, the time spent by the transaction in each of the Java components (FILTER,
STRUTS, SERVLETS, JSPS, POJOS, SQL, JDBC, etc.) will be listed, thus leading you to the exact Java component
where the slowdown occurred.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Figure 2.5: The detailed diagnosis of the Slow transactions measure
You can even perform detailed method-level analysis to isolate the methods taking too long to
execute. For this, click on the URL Tree link. Figure 2.6 will then appear. In the left panel of Figure 2.6,
you will find the list of transactions that match a configured pattern; these transactions will be sorted
in the descending order of their Total Response Time (by default). This is indicated by the Total
Response Time option chosen by default from the Sort by list in Figure 2.6. If you select a transaction
from the left panel, an At-A-Glance tab page will open by default in the right panel, providing quick, yet
deep insights into the performance of the chosen transaction and the reasons for its slowness. This
tab page begins by displaying the URL of the chosen transaction, the total Response time of the
transaction, the time at which the transaction was last requested, and the Remote Host from which the
request was received.
If the Response time appears to be very high, then you can take a look at the Method Level Breakup
section to figure out which method called by which Java component (such as FILTER, STRUTS, SERVLETS,
JSPS, POJOS, SQL, JDBC, etc.) could have caused the slowdown. This section provides a horizontal bar
graph, which reveals the percentage of time for which the chosen transaction spent executing each of
the top methods (in terms of execution time) invoked by it. The legend below clearly indicates the top
methods and the layer/sub-component that invoked each method. Against every method, the number
of times that method was invoked in the Measurement Time, the Duration (in Secs) for which the method
executed, and the percentage of the total execution time of the transaction for which the method was
in execution will be displayed, thus quickly pointing you to those methods that may have contributed
to the slowdown. The methods displayed here and featured in the bar graph depend upon the METHOD
EXEC CUTOFF configuration of this test - in other words, only those methods with an execution
duration that exceeds the threshold limit configured against METHOD EXEC CUTOFF will be displayed
in the Method Level Breakup section.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Figure 2.6: The Method Level Breakup section in the At-A-Glance tab page
While the Method Level Breakup section provides method-level insights into responsiveness, for a subcomponent or layer level breakup of responsiveness scroll down the At-A-Glance tab to view the
Component Level Breakup section (see Figure 2.7). Using this horizontal bar graph, you can quickly tell
where - i.e., in which Java component - the transaction spent the maximum time. A quick glance at
the graph's legend will reveal the Java components the transaction visited, the number of methods
invoked by Java component, the Duration (Secs) for which the transaction was processed by the Java
component, and what Percentage of the total transaction response time was spent in the Java
component.

Figure 2.7: The Component Level Breakup section in the At-A-Glance tab page

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Besides Java methods, where the target Java application interacts with the database, long-running
SQL queries can also contribute to the poor responsiveness of a transaction. You can use the At-AGlance tab page to determine whether the transaction interacts with the database or not, and if so,
how healthy that interaction is. For this, scroll down the At-A-Glance tab page.

Figure 2.8: Query Details in the At-A-Glance tab page
Upon scrolling, you will find query details below the Component Level Breakup section. All the SQL queries
that the chosen transaction executes on the backend database will be listed here in the descending
order of their Duration. Corresponding to each query, you will be able to view the number of times that
query was executed, the Duration for which it executed, and what percentage of the total transaction
response time was spent in executing that query. A quick look at this tabulation would suffice to
identify the query which executed for an abnormally long time on the database, causing the
transaction's responsiveness to suffer. For a detailed query description, click on the query. Figure 2.9
will then pop up displaying the complete query and its execution duration.

Figure 2.9: Detailed description of the query clicked on

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

This way, the At-A-Glance tab page allows you to analyze, at-a-glance, all the factors that can influence
transaction response time - be it Java methods, Java components, and SQL queries - and enables you
to quickly diagnose the source of a transaction slowdown. If, for instance, you figure out that a
particular Java method is responsible for the slowdown, you can zoom into the performance of the
'suspect method' by clicking on that method in the Method Level Breakup section of the At-A-Glance tab
page. This will automatically lead you to the Trace tab page, where all invocations of the chosen
method will be highlighted (see Figure 2.10).

Figure 2.10: The Trace tab page displaying all invocations of the method chosen from the Method Level Breakup
section
Typically, clicking on the Trace tab page will list all the methods invoked by the chosen transaction,
starting with the very first method. Methods and sub-methods (a method invoked within a method)
are arranged in a tree-structure, which can be expanded or collapsed at will. To view the sub-methods
within a method, click on the arrow icon that precedes that method in the Trace tab page. Likewise, to
collapse a tree, click once again on the arrow icon. Using the tree-structure, you can easily trace the
sequence in which methods are invoked by a transaction.
If a method is chosen for analysis from the Method Level Breakup section of the At-A-Glance tab page, the
Trace tab page will automatically bring your attention to all invocations of that method by highlighting
them (as shown by Figure 2.10). Likewise, if a Java component is clicked in the Component Level
Breakup section of the At-A-Glance section, the Trace tab page will automatically appear, displaying all
the methods invoked from the chosen Java component (as shown by Figure 2.11).

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Figure 2.11: The Trace tab page displaying all methods invoked at the Java layer/sub-component chosen from the
Component Level Breakup section
For every method, the Trace tab page displays a Request Processing bar, which will accurately indicate
when, in the sequence of method invocations, the said method began execution and when it ended;
with the help of this progress bar, you will be able to fairly judge the duration of the method, and also
quickly tell whether any methods were called prior to the method in question. In addition, the Trace tab
page will also display the time taken for a method to execute ( Method Execution Time) and the
percentage of the time the transaction spent in executing that method. The most time-consuming
methods can thus be instantly isolated.
The Trace tab page also displays the Total Execution Time for each method - this value will be the same
as the Method Execution Time for 'stand-alone' methods - i.e., methods without any sub-methods. In the
case of methods with sub-methods however, the Total Execution Time will be the sum total of the Method
Execution Time of each sub-method invoked within. This is because, a 'parent' method completes
execution only when all its child/sub-methods finish executing.
With the help of the Trace tab page therefore, you can accurately trace the method that takes the
longest to execute, when that method began execution, and which 'parent method' (if any) invoked
the method.
Next, click on the SQL/Errors tab page. This tab page lists all the SQL queries the transaction executes
on its backend database, and/or all the errors detected in the transaction's Java code. The query list
(see Figure 2.12) is typically arranged in the descending order of the query execution Duration, and
thus leads you to the long-running queries right away! You can even scrutinize the time-consuming
query on-the-fly, and suggest improvements to your administrator instantly.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Figure 2.12: Queries displayed in the SQL/Error tab page
When displaying errors, the SQL/Error tab page does not display the error message alone, but displays
the complete code block that could have caused the error to occur. By carefully scrutinizing the block,
you can easily zero-in on the 'exact line of code' that could have forced the error - this means that
besides pointing you to bugs in your code, the SQL/Error tab page also helps you initiate measures to
fix the same.

Figure 2.13: Errors displayed in the SQL/Error tab page

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

This way, with the help of the three tab pages - At-A-Glance, Trace, and SQL/Error - you can effectively
analyze and accurately diagnose the root-cause of slowdowns in transactions to your Java
applications.
The detailed diagnosis of the Error transactions measure reveals the top-10 (by default) transactions,
in terms of TOTAL RESPONSE TIME, that have encountered errors. To know the nature of the errors that
occurred, click on the URL Tree icon in Figure 2.14. This will lead you to the URL Tree window, which has
already been elaborately discussed.

Figure 2.14: The detailed diagnosis of the Error transactions measure

2.1.2.6.1

JVM GC Test

Manual memory management is time consuming, and error prone. Most programs still contain leaks.
This is all doubly true with programs using exception-handling and/or threads. Garbage collection (GC)
is a part of WebLogic's JVM that automatically determines what memory a program is no longer using,
and recycles it for other use. It is also known as "automatic storage (or memory) reclamation''. The
JVMGCTest reports the performance statistics pertaining to the JVM's garbage collection.

Purpose

Reports the performance statistics pertaining to the JVM's garbage collection

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST – The IP address of the WebLogic server
3. PORT – The port number of the WebLogic server
4. JREHOME – The path to the directory in which the JVM to be monitored exists
5. LOGFILENAME – The full path to the log file which stores the GC output.
6. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for every GC

Measurement
Number of GC:

Measurement
Unit
Number

The number of times
garbage collection has
happened.

Interpretation
If adequate memory is not allotted to
the JVM, then the value of this measure
would be very high. A high value of this
measure is indicative of a high frequency
of GC. This is not a good sign, as GC,
during its execution, has the tendency of
suspending an application, and a high
frequency of GC would only adversely
impact the application's performance. To
avoid this, it is recommended that you
allot sufficient memory to the JVM.
The detailed diagnosis of the Number of
GC measure, if enabled, provides details
such as the heap size before GC was
performed, the heap size after GC was
performed, and the total time spent by
the JVM in garbage collection. The
difference between the heap sizes will
help administrators figure out how
effective GC is. The total GC time will
help administrators gauge how severely
GC
has
impacted
application
performance

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Total GC time:

S e r v e r s

Secs

If adequate memory is not allotted to
the JVM, then the value of this measure
would be very high. This is not a good
sign, as GC, during its execution, has
the
tendency
of
suspending
an
application, and a high value of this
measure would only adversely impact
the application's performance. To avoid
this, it is recommended that you allot
sufficient memory to the JVM.

Avg GC frequency:
The frequency with
which the JVM
performed GC.

Sec

If adequate memory is not allotted to
the JVM, then the value of this measure
would be very low. A low value of this
measure is indicative of a high frequency
of GC. This is not a good sign, as GC,
during its execution, has the tendency of
suspending an application, and a high
frequency of GC would only adversely
impact the application's performance. To
avoid this, it is recommended that you
allot sufficient memory to the JVM.

Avg GC pause:

Secs

If the garbage collection takes more
time to complete, then it indicates a
very high memory allocation to the JVM.
This
again
hinders
application
performance.

Percent

By carefully examining the application
behavior in terms of memory utilization,
you should arrive at an optimal ratio of
the number of times the GC needs to run
and how long it should take to complete.
Accordingly, memory allocation to the
JVM can be performed.

The sum of the time
taken by all garbage
collections.

The average time the
application is suspended
while garbage collection
is in progress.
Avg GC overhead:
The percentage of time
utilized by the JVM for
garbage collection

Max GC pause:

Secs

The
maximum
time
spent by the JVM on
garbage
collection,
during
the
last
measurement period
Avg heap before GC:

The average heap size
prior
to
garbage
collection
Avg heap after GC:

The difference between the value of this
measure and the Avg heap before GC
measure provides the amount of
memory that has been released by GC.
This value is a good indicator of the
effectiveness of GC.

The average heap size
after garbage collection

M o n i t o r i n g

2.1.2.6.2

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Java Classes Test

This test reports the number of classes loaded/unloaded from the memory.

Purpose

Reports the number of classes loaded/unloaded from the memory

Target of the
test

A WebLogic server

Agent
deploying the
test

An internal/remote agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT - The port number at which the specified HOST listens
4. MODE – This test can extract metrics from the Java application using either of
the following mechanisms:



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (see
page 13).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm

13. ENCRYPTFLAG – This flag appears only when v3 is selected as the
SNMPVERSION. By default, the eG agent does not encrypt SNMP requests.
Accordingly, the ENCRYPTFLAG is set to NO by default. To ensure that SNMP
requests sent by the eG agent are encrypted, select the YES option.
14. ENCRYPTTYPE – If the ENCRYPTFLAG is set to YES, then you will have to
mention the encryption type by selecting an option from the ENCRYPTTYPE list.
SNMP v3 supports the following encryption types:



DES – Data Encryption Standard



AES – Advanced Encryption Standard

Outputs of the
test
Measurements
made by the
test

One set of results for the server being monitored

Measurement
Unit

Measurement
Classes loaded:

Number

Indicates the number of classes
currently loaded into memory.

Interpretation
Classes are fundamental to the
design of Java programming
language.
Typically,
Java

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Classes unloaded:

Number

Indicates the number of classes
currently
unloaded
from
memory.

Total classes loaded:

applications install a variety of
class loaders (that is, classes that
implement java.lang.ClassLoader)
to allow different portions of the
container, and the applications
running on the container, to have
access to different repositories of
available classes and resources. A
consistent
decrease
in
the
number of classes loaded and
unloaded could indicate a roadblock in the loading/unloading of
classes by the class loader. If left
unchecked,
critical
resources/classes
could
be
rendered inaccessible to the
application,
thereby
severely
affecting its performance.

Number

Indicates the total number of
classes loaded into memory
since the JVM started, including
those subsequently unloaded.

2.1.2.6.3

JVM Threads Test

This test reports the status of threads on the JVM, and also reveals resource-hungry threads, so that
threads that are unnecessarily consuming CPU resources can be killed.

Purpose

Reports the status of threads on the JVM, and also reveals resource-hungry threads,
so that threads that are unnecessarily consuming CPU resources can be killed

Target of the
test

A WebLogic server

Agent
deploying the
test

An internal/remote agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

15. ENCRYPTPASSWORD – Specify the encryption password here.
16. CONFIRM PASSWORD – Confirm the encryption password by retyping it here.
17. TIMEOUT - This parameter appears only if the MODE is set to SNMP. Here, specify
the duration (in seconds) within which the SNMP query executed by this test
should time out in the TIMEOUT text box. The default is 10 seconds.
18. PCT LOW CPU UTIL THREADS – This test reports the number of threads in the
JVM that are consuming low CPU. This thread count will include only those
threads for which the CPU usage is equal to or lesser than the value specified in
the PCT LOW CPU UTIL THREADS text box. The default value displayed here is
30.
19. PCT MEDIUM CPU UTIL THREADS - This test reports the number of threads in the
JVM that are consuming CPU to a medium extent. This thread count will include
only those threads for which the CPU usage is higher than the PCT LOW CPU
UTIL THREADS configuration and is lower than or equal to the value specified in
the PCT MEDIUM CPU UTIL THREADS text box. The default value displayed here
is 50.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

20. PCT HIGH CPU UTIL THREADS - This test reports the number of threads in the
JVM that are consuming high CPU. This thread count will include only those
threads for which the CPU usage is either greater than the PCT MEDIUM CPU
UTIL THREADS configuration, or is equal to or greater than the value specified in
the PCT HIGH CPU UTIL THREADS text box. The default value displayed here is
70.
21. DD FREQUENCY - Refers to the frequency with which detailed
diagnosis measures are to be generated for this test. The default is 1:1. This
indicates that, by default, detailed measures will be generated every time this
test runs, and also every time the test detects a problem. You can modify this
frequency, if you so desire. Also, if you intend to disable the detailed diagnosis
capability for this test, you can do so by specifying none against DD
FREQUENCY.
22. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for the server being monitored

Measurement
Unit

Measurement
Total threads:

Interpretation

Number

Indicates the total number of
threads (including daemon and
non-daemon threads).
Runnable threads:

Number

The detailed diagnosis of this
measure, if enabled, provides the
name of the threads, the CPU
usage by the threads, the time
for which the thread was in a
blocked state, waiting state, etc.

Number

If a thread is trying to take a lock
(to enter a synchronized block),
but the lock is already held by
another thread, then such a
thread is called a blocked thread.

Indicates the current number of
threads in a runnable state.

Blocked threads:
Indicates the number of threads
that are currently in a blocked
state.

The detailed diagnosis of this
measure, if enabled, provides indepth information related to the
blocked threads.
58

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Waiting threads:

Number

Indicates the number of threads
that are currently in a waiting
state.

A thread is said to be in a Waiting
state if the thread enters a
synchronized block, tries to take
a lock that is already held by
another thread, and hence, waits
till the other thread notifies that it
has released the lock.
Ideally, the value of this measure
should be low. A very high value
could be indicative of excessive
waiting activity on the JVM. You
can use the detailed diagnosis of
this measure, if enabled, to figure
out which threads are currently in
the waiting state.
While
waiting,
the
Java
application program does no
productive work and its ability to
complete the task-at-hand is
degraded. A certain amount of
waiting may be acceptable for
Java
application
programs.
However, when the amount of
time spent waiting becomes
excessive or if the number of
times that waits occur exceeds a
reasonable amount, the Java
application program may not be
programmed correctly to take
advantage
of
the
available
resources. When this happens,
the delay caused by the waiting
Java
application
programs
elongates the response time
experienced by an end user. An
enterprise
may
use
Java
application programs to perform
various functions. Delays based
on
abnormal
degradation
consume employee time and may
be costly to corporations.

Timed waiting threads:

Number

Indicates the number of threads
in a TIMED_WAITING state.

When a thread is in the
TIMED_WAITING state, it implies
that the thread is waiting for
another thread to do something,
but will give up after a specified
time out period.
To view the details of threads in
the TIMED_WAITING state, use
the detailed diagnosis of this
measure, if enabled.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Low CPU threads:

Number

Indicates the number of threads
that are currently consuming
CPU lower than the value
configured in the PCT LOW CPU
UTIL THREADS text box.
Medium CPU threads:

Number

Indicates the number of threads
that are currently consuming
CPU that is higher than the value
configured in the PCT LOW CPU
UTIL THREADS text box and is
lower than or equal to the value
specified in the PCT MEDIUM CPU
UTIL THREADS text box.
High CPU threads:

Number

Indicates the number of threads
that are currently consuming
CPU that is either greater than
the percentage configured in the
PCT MEDIUM CPU UTIL THREADS
or lesser than or equal to the
value configured in the PCT HIGH
CPU UTIL THREADS text box.

Peak threads:

Ideally, the value of this measure
should be very low. A high value
is indicative of a resource
contention at the JVM. Under
such circumstances, you might
want to identify the resourcehungry threads and kill them, so
that application performance is
not hampered. To know which
threads are consuming excessive
CPU, use the detailed diagnosis of
this measure.

Number

Indicates the highest number of
live threads since JVM started.
Started threads:

Number

Indicates the the total number of
threads
started
(including
daemon,
non-daemon,
and
terminated) since JVM started.
Daemon threads:

Number

Indicates the current number of
live daemon threads.
Deadlock threads:

Number

Indicates the current number of
deadlocked threads.

Ideally, this value should be 0. A
high value is a cause for concern,
as it indicates that many threads
are blocking one another causing
the application performance to
suffer. The detailed diagnosis of
this measure, if enabled, lists the
deadlocked threads and their
resource usage.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
If the MODE for the JVM Threads test is set to SNMP, then the detailed diagnosis of this test will not
display the Blocked Time and Waited Time for the threads. To make sure that detailed diagnosis
reports these details also, do the following:



Go to the \jre\lib\management folder used by the WebLogic server, and edit the
management.properties file in that folder.



Append the following line to the file:
com.sun.management.enableThreadContentionMonitoring



Finally, save the file.

Note:
While viewing the measures reported by the JVM Thread test, you can also view the resource usage
details and the stack trace information for all the threads, by clicking on the STACK TRACE link in the
Measurements panel.
A stack trace (also called stack backtrace or stack traceback) is a report of the active stack
frames instantiated by the execution of a program. It is commonly used to determine what threads
are currently active in the JVM, and which threads are in each of the different states – i.e., alive,
blocked, waiting, timed waiting, etc.
Typically, when the JVM begins exhibiting erratic resource usage patterns, it often takes
administrators hours, even days to figure out what is causing this anomaly – could it be owing to
one/more resource-intensive threads being executed by the WebLogic server? If so, what is
causing the thread to erode resources? Is it an inefficient piece of code? In which case, which line
of code could be the most likely cause for the spike in resource usage? To be able to answer these
questions accurately, administrators need to know the complete list of threads that are executing
on the JVM, view the stack trace of each thread, analyze each stack trace in a top-down manner,
and trace where the problem originated.

2.1.2.6.4

JVM Cpu Usage Test

This test measures the CPU utilization of the JVM. If the JVM experiences abnormal CPU usage levels,
you can use this test to instantly drill down to the classes and the methods within the classes that
contributing to the resource contention at the JVM.

Purpose

Reports the status of threads on the JVM, and also reveals resource-hungry threads,
so that threads that are unnecessarily consuming CPU resources can be killed

Target of the
test

A WebLogic server

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (see refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to refer to the Monitoring Java Applications document. Confirm the
password by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

15. ENCRYPTPASSWORD – Specify the encryption password here.
16. CONFIRM PASSWORD – Confirm the encryption password by retyping it here.
17. TIMEOUT - This parameter appears only if the MODE is set to SNMP. Here, specify
the duration (in seconds) within which the SNMP query executed by this test
should time out in the TIMEOUT text box. The default is 10 seconds.
18. PROFILER HOME – JIP (Java Interactive Profiler) is a high performance, low
overhead profiler that is written entirely in Java and used extensively to gather
performance data pertaining to a JVM. The eG agent comes bundled with JIP,
and takes the help of JIP to provide detailed diagnosis information related to the
CPU usage of the JVM. To make sure that this test contacts JIP for detailed
resource usage metrics, you need to indicate the location of the JIP in the
PROFILER HOME text box.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Typically, the files related to this profiler are available in \lib\jip
directory (in Windows; in Unix, this will be: /opt/egurkha/lib/jip). If only a single
Java application on a host is being monitored, then the jip folder can remain in
the same location. The PROFILER HOME parameter should then be configured
with /opt/egurkha/lib/jip or \lib\jip, as the case may be. However, if
more than one Java application on a single host is to be monitored, then first
ensure that the jip folder is copied to two different locations on the same host.
The PROFILER HOME parameter should in this case be configured with the
location of the jip folder that corresponds to the Java application for which this
test is being currently configured. For instance, say japp1 and japp2 are 2 Java
applications that are being managed by the eG Enterprise system. Assume that
the jip folder has been copied to the C:\japp1 and D:\japp2 folders. Now, while
configuring this test for the japp1 application, specify C:\japp\jip in PROFILER
HOME. Similarly, when configuring this test for the japp2 application, enter
D:\japp2\jip in PROFILER HOME.
19. PROFILER – The JIP can be turned on or off while the JVM is still running. For
the eG agent to be able to report detailed diagnosis of the CPU usage metric,
the profiler should be turned on. Accordingly, the PROFILER flag is set to On by
default. If you do not want detailed diagnosis, then you can set the PROFILER
flag to Off.
20. DD FREQUENCY - Refers to the frequency with which detailed
diagnosis measures are to be generated for this test. The default is 1:1. This
indicates that, by default, detailed measures will be generated every time this
test runs, and also every time the test detects a problem. You can modify this
frequency, if you so desire. Also, if you intend to disable the detailed diagnosis
capability for this test, you can do so by specifying none against DD
FREQUENCY.
21. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for the server being monitored

Measurement
Unit

Measurement

Interpretation

M o n i t o r i n g

test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

CPU utilization of JVM:

Percent

Indicates the percentage of CPU
currently utilized by the JVM.

2.1.2.6.5

Ideally, this value should be low.
An unusually high value or a
consistent increase in this value is
indicative of abnormal CPU usage,
and
could
warrant
further
investigation. In such a situation,
you
can
use
the
detailed
diagnosis of this measure, if
enabled, to determine which
methods
invoked
by
which
classes
are
causing
the
steady/sporadic spikes in CPU
usage.

JVM Memory Usage Test

This test monitors every memory type on the JVM and reports how efficiently the JVM utilizes the
memory resources of each type.

Purpose

Monitors every memory type on the JVM and reports how efficiently the JVM utilizes
the memory resources of each type

Target of the
test

A WebLogic server

Agent
deploying the
test

An internal/remote agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (see refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to refer to the Monitoring Java Applications document. Confirm the
password by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm

15. ENCRYPTFLAG – This flag appears only when v3 is selected as the
SNMPVERSION. By default, the eG agent does not encrypt SNMP requests.
Accordingly, the ENCRYPTFLAG is set to NO by default. To ensure that SNMP
requests sent by the eG agent are encrypted, select the YES option.
16. ENCRYPTTYPE – If the ENCRYPTFLAG is set to YES, then you will have to
mention the encryption type by selecting an option from the ENCRYPTTYPE list.
SNMP v3 supports the following encryption types:



DES – Data Encryption Standard



AES – Advanced Encryption Standard

Outputs of the
test
Measurements
made by the

One set of results for every memory type on the JVM being monitored

Measurement
Unit

Measurement

Interpretation

M o n i t o r i n g

test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Initial memory:

The detailed diagnosis of this
measure, when enabled, reveals
the memory pools on the JVM,
the memory type of every pool,
and
the
memory
manager
managing the pool.

It includes the memory occupied
by all objects including both
reachable
and
unreachable
objects.

The
amount
of
Available
memory may change over time.
The Java virtual machine may
release memory to the system
and committed memory could be
less than the amount of memory
initially allocated at startup.
Committed will always be greater
than or equal to used memory.

This is the difference between
Available memory and Used
memory.

Indicates the amount of memory
initially allocated at startup.

Used memory:
Indicates the amount of memory
currently used.
Available memory:
Indicates the amount of memory
guaranteed to be available for
use by the JVM.

Free memory:
Indicates the amount of memory
currently available for use by the
JVM.

Ideally, the value of this measure
should be high.

Max free memory:

Indicates the maximum amount
of memory allocated for the JVM.
Used percentage:

Percent

Indicates the percentage of used
memory.

2.1.2.6.6

Ideally, the value of this measure
should be low. A very high value
of this measure could indicate
excessive memory consumption
by the JVM, which in turn, could
warrant further investigation.

JVM Uptime Test

This test helps track whether a scheduled reboot of the JVM has occurred or not.

Purpose

Helps track whether a scheduled reboot of the JVM has occurred or not

Target of the
test

A WebLogic server

Agent
deploying the
test

An internal/remote agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (see refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

Outputs of the
test
Measurements
made by the

One set of results for the server being monitored

Measurement
Unit

Measurement

Interpretation

M o n i t o r i n g

test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Has JVM been restarted?:

If the value of this measure is No,
it indicates that the JVM has not
restarted. The value Yes on the
other hand implies that the JVM
has indeed restarted.

Indicates whether or not the JVM
has restarted during the last
measurement period.

The
numeric
values
that
correspond to the reboot states
discussed above are listed in the
table below:
State

Value

Yes

Note:
By default, this measure reports
the value Yes or No to indicate
whether a JVM has restarted. The
graph of this measure however,
represents the same using the
numeric equivalents – 0 or 1.
Uptime during the last
measure period:

Secs

If the JVM has not been restarted
during the last measurement
period and the agent has been
running continuously, this value
will be equal to the measurement
period. If the JVM was restarted
during the last measurement
period, this value will be less than
the measurement period of the
test.
For
example,
if
the
measurement period is 300 secs,
and if the JVM was restarted 120
secs back, this metric will report a
value of 120 seconds.
The
accuracy
of
this
metric
is
dependent on the measurement
period
–
the
smaller
the
measurement period, greater the
accuracy.

Secs

Administrators may wish to be
alerted if a JVM has been running
without a reboot for a very long
period. Setting a threshold for
this metric allows administrators
to determine such conditions.

Indicates the time period that
the JVM has been up since the
last time this test ran.

Total uptime of the JVM:
Indicates the total time that the
JVM has been up since its last
reboot.

M o n i t o r i n g

2.1.2.6.7

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

JVM Garbage Collections Test

Manual memory management is time consuming, and error prone. Most programs still contain leaks.
This is all doubly true with programs using exception-handling and/or threads. Garbage collection (GC)
is a part of a Java application’s JVM that automatically determines what memory a program is no
longer using, and recycles it for other use. It is also known as "automatic storage (or memory)
reclamation''. The JvmGarbageCollection test reports the performance statistics pertaining to the
JVM's garbage collection.

Purpose

Reports the performance statistics pertaining to the JVM's garbage collection

Target of the
test

A WebSphere server

Agent
deploying the
test

An internal/remote agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

Outputs of the
test
Measurements
made by the

One set of results for every garbage collector configured on the WebSphere server
being monitored

Measurement
Unit

Measurement

Interpretation

M o n i t o r i n g

test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

No of garbage collections
started:

Number

Indicates the number of times
garbage collection started to
release
dead
objects
form
memory.
Time taken for garbage
collection:

Secs

Indicates the time taken to
perform the current garbage
collection operation.
Percent of time spent by JVM
for garbage collection:

Percent

Indicates the percentage of time
spent by JVM in garbage
collection.

2.1.2.6.8

Ideally, the value of both these
measures should be low. This is
because, the garbage collection
(GC) activity tends to suspend
the operations of the application
until such time that GC ends.
Longer the GC time, longer it
would take for the application to
resume its functions. To minimize
the impact of GC on application
performance, it is best to ensure
that GC activity does not take too
long to complete.

JVM Memory Pool Garbage Collections Test

While the JVM Garbage Collections test reports statistics indicating how well each collector on the JVM
performs garbage collection, the measures reported by the JVM Memory Pool Garbage Collections test help
assess the impact of the garbage collection activity on the availability and usage of memory in each
memory pool of the JVM. Besides revealing the count of garbage collections per collector and the time
taken by each collector to perform garbage collection on the individual memory pools, the test also
compares the amount of memory used and available for use pre and post garbage collection in each of
the memory pools. This way, the test enables administrators to guage the effectiveness of the
garbage collection activity on the memory pools, and helps them accurately identify those memory
pools where enough memory could not reclaimed or where the garbage collectors spent too much
time.

Purpose

Helps assess the impact of the garbage collection activity on the availability and
usage of memory in each memory pool of the JVM

Target of the
test

A WebSphere Application Server

Agent
deploying the
test

An internal/remote agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT - The port number at which the specified HOST listens
4. MEASURE MODE - This test allows you the option to collect the desired metrics
using one of the following methodologies:



By contacting the Java runtime (JRE) of the application via JMX



Using GC logs

To use JMX for metrics collections, set the MEASURE MODE to JMX.
On the other hand, if you intend to use the GC log files for collecting the
required metrics, set the MEASURE MODE to Log File. In this case, you would be
required to enable GC logging. The procedure for this has been detailed in the
Monitoring Java Applications document.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. JREHOME - This parameter will be available only if the MEASURE MODE is set to
Log File. Specify the full path to the Java Runtime Environment (JRE) used by
the target application.
9. LOGFILENAME - This parameter will be available only if the MEASURE MODE is
set to Log File. Specify the full path to the GC log file to be used for metrics
collection.

Outputs of the
test
Measurements
made by the
test

One set of results for every GarbageCollector:MemoryPool pair on the JVM of the
server being monitored

Measurement
Unit

Measurement
Has garbage collection
happened?:
Indicates
whether
collection
occurred
memory
pool
in
measurement period.

Interpretation
This measure reports the value
Yes if garbage collection took
place or No if it did not take place
on the memory pool.

garbage
on
this
the
last

The
numeric
values
that
correspond to the measure values
of Yes and No are listed below:

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

State

Value

Yes

Note:
By default, this measure reports
the value Yes or No to indicate
whether a GC occurred on a
memory pool or not. The graph of
this measure however, represents
the same using the numeric
equivalents – 0 or 1.
Collection count:

Number

Indicates the number of time in
the last measurement pool
garbage collection was started
on this memory pool.
Initial memory before GC:

Indicates the initial amount of
memory (in MB) that this
memory pool requests from the
operating system for memory
management
during
startup,
before GC process.
Initial memory after GC:

Indicates the initial amount of
memory (in MB) that this
memory pool requests from the
operating system for memory
management
during
startup,
after GC process

Comparing the value of these two
measures for a memory pool will
give you a fair idea of the
effectiveness of the garbage
collection activity.
If garbage collection reclaims a
large amount of memory from the
memory pool, then the Initial
memory after GC will drop. On
the other hand, if the garbage
collector does not reclaim much
memory from a memory pool, or
if the Java application suddenly
runs a memory-intensive process
when GC is being performed, then
the Initial memory after GC may
be higher than the Initial memory
before GC.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Max memory before GC:

Indicates the maximum amount
of memory that can be used for
memory management by this
memory pool, before GC
process.
Max memory after GC:

Indicates the maximum amount
of memory (in MB) that can be
used for memory management
by this pool, after the GC
process.

Committed memory before
GC:

Comparing the value of these two
measures for a memory pool will
provide you with insights into the
effectiveness of the garbage
collection activity.
If garbage collection reclaims a
large amount of memory from the
memory pool, then the Max
memory after GC will drop. On
the other hand, if the garbage
collector does not reclaim much
memory from a memory pool, or
if the Java application suddenly
runs a memory-intensive process
when GC is being performed, then
the Max memory after GC value
may exceed the Max memory
before GC.

Indicates the amount of memory
that
is
guaranteed
to
be
available for use by this memory
pool, before the GC process.
Committed memory after GC:

Indicates the amount of memory
that
is
guaranteed
to
be
available for use by this memory
pool, after the GC process.
Used memory before GC:

Indicates the amount of memory
used by this memory pool before
GC.
Used memory after GC:

Indicates the amount of memory
used by this memory pool after
GC.

Comparing the value of these two
measures for a memory pool will
provide you with insights into the
effectiveness of the garbage
collection activity.
If garbage collection reclaims a
large amount of memory from the
memory pool, then the Used
memory after GC may drop lower
than the Used memory before
GC. On the other hand, if the
garbage
collector
does
not
reclaim much memory from a
memory pool, or if the Java
application
suddenly
runs
a
memory-intensive process when
GC is being performed, then the
Used memory after GC value may
exceed the Used memory before
GC.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Percentage memory
collected:

Percent

A high value for this measure is
indicative of a large amount of
unused memory in the pool. A
low value on the other hand
indicates that the memory pool
has been over-utilized. Compare
the value of this measure across
pools to identify the pools that
have very little free memory. If
too many pools appear to be
running short of memory, it could
indicate
that
the
target
application is consuming too
much memory, which in the long
run,
can
slow
down
the
application significantly.

Mins

Ideally, the value of this measure
should be low. This is because,
the
garbage
collection (GC)
activity tends to suspend the
operations of the application until
such time that GC ends. Longer
the GC time, longer it would take
for the application to resume its
functions. To minimize the impact
of GC on application performance,
it is best to ensure that GC
activity does not take too long to
complete.

Indicates the percentage of
memory collected from this pool
by the GC activity.

Collection duration:
Indicates the time taken by this
garbage collector for collecting
unused memory from this pool.

2.1.2.6.9

JMX Connection to JVM

This test reports the availability of the target Java application, and also indicates whether JMX is
enabled on the application or not. In addition, the test promptly alerts you to slowdowns experienced
by the application, and also reveals whether the application was recently restarted or not.

Purpose

Reports the availability of the target Java application, and also indicates whether
JMX is enabled on the application or not. In addition, the test promptly alerts you to
slowdowns experienced by the application, and also reveals whether the application
was recently restarted or not

Target of the
test

A Java application

Agent
deploying the
test

An internal/remote agent

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT - The port number at which the specified HOST listens
4. JMX REMOTE PORT – Here, specify the port at which the JMX listens for requests
from remote hosts. Ensure that you specify the same port that you configured in
the management.properties file in the \jre\lib\management folder used
by the target application (refer to the Monitoring Java Applications document).
5. USER, PASSWORD, and CONFIRM PASSWORD – If JMX requires authentication only
(but no security), then ensure that the USER and PASSWORD parameters are
configured with the credentials of a user with read-write access to JMX. To know
how to create this user, refer to the Monitoring Java Applications document.
Confirm the password by retyping it in the CONFIRM PASSWORD text box.
6. JNDINAME – The JNDINAME is a lookup name for connecting to the JMX connector.
By default, this is jmxrmi. If you have registered the JMX connector in the RMI
registry using a different lookup name, then you can change this default value
to reflect the same.

Outputs of the
test
Measurements
made by the
test

One set of results for the Java application being monitored

Measurement
Unit

Measurement
JMX availability:

Percent

Indicates whether the target
application is available or not
and whether JMX is enabled or
not on the application.

Interpretation
If the value of this measure is
100%, it indicates that the Java
application is available with JMX
enabled. The value 0 on the other
hand, could indicate one/both the
following:

The

Java application
unavailable;

The

Java application is
available, but JMX is not
enabled;

JMX response time:

Secs

Indicates the time taken to
connect to the JMX agent of the
Java application.
Has the PID changed?

A high value could indicate a
connection bottleneck.

This measure will report the value
Yes if the PID of the target
application has changed; such a
change is indicative of an
application
restart.
If
the
application has not restarted i.e., if the PID has not changed then this measure will return the
value No.

Indicates whether/not the
process ID that corresponds to
the Java application has
changed.

M o n i t o r i n g

2.1.2.6.10

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

JVM File Descriptors Test

This test reports useful statistics pertaining to file descriptors.

Purpose

Reports useful statistics pertaining to file descriptors

Target of the
test

A Java application

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

One set of results for the Java application being monitored

Measurement
Unit

Measurement
Open file descriptors in JVM:

Number

Indicates the number of file
descriptors currently open for
the application.
Maximum file descriptors in
JVM:

Number

Indicates the maximum number
of file descriptors allowed for the
application.
File descriptor usage by JVM:

Percent

Indicates the file descriptor
usage in percentage.

Interpretation

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

2.1.3 The WebLogic Service Layer
The WebLogic Service layer tracks the health of the WebLogic service. The status of the WebLogic Service
layer is determined by the results of the tests shown in Figure 2.15.

Figure 2.15: Tests mapping to the WebLogic Service layer

2.1.3.1

HTTP Test

The details of the HTTP test that emulates a user accessing the web server component of a WebLogic
server, are provided below. Since this test can be executed from a location external to the WebLogic
server, this test presents an unbiased external perspective of the state of the web server component.
This test uses the GET command to submit its parameters.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Purpose

This test measures the state of the web server component of a WebLogic server

Target

A WebLogic server

Agent
deploying this
test

An external agent executing on an eG server

Configurable
parameters for
this test

1. TEST PERIOD – How often should the test be executed
2. URL – The web page being accessed. While multiple URLs (separated by
commas) can be provided, each URL should be of the format URL name:URL
value. URL name is a unique name assigned to the URL, and the URL value is
the value of the URL. For example, a URL can be specified as
HomePage:http://192.168.10.12:7077/, where HomePage is the URL
name and http://192.168.10.12:7077/ is the URL value.

3. HOST - The host for which the test is to be configured.
4. PORT - The port to which the specified HOST listens
5. COOKIEFILE – Whether any cookies being returned by the web server need to
be saved locally and returned with subsequent requests

6. PROXYHOST – The host on which a web proxy server is running (in case a proxy
server is to be used)

7. PROXYPORT – The port number on which the web proxy server is listening
8. PROXYUSERNAME – The user name of the proxy server
9. PROXYPASSWORD – The password of the proxy server
10. CONFIRM PASSWORD – Confirm the password by retyping it here.
11. CONTENT – Is a set of instruction:value pairs that are used to validate the
content being returned by the test. If the CONTENT value is none:none, no
validation is performed. The number of pairs specified in this text box, must be
equal to the number of URLs being monitored. The instruction should be one of
Inc or Exc. Inc tells the test that for the content returned by the web server to
be valid, the content must include the specified value (a simple string search is
done in this case). An instruction of Exc instructs the test that the server's
output is valid if it does not contain the specified value. In both cases, the
content specification can include wild card patterns. For example, an Inc
instruction can be Inc:*Home page*. An Inc and an Exc instruction can be
provided in quick succession in the following format: Inc:*Home
Page*,Exc:*home.

12. CREDENTIALS – The HttpTest supports HTTP authentication. The CREDENTIALS
parameter is to be set if a specific user name / password has to be specified to
login to a page. Against this parameter, the URLname of every configured URL
will be displayed; corresponding to each listed URLname, a Username text box
and a Password text box will be made available. If the web server on which
HttpTest executes supports 'Anonymous user access', then this parameter will
take either of the following values:

a valid Username and Password for every configured URLname

none in both the Username and Password text boxes of all configured
URLnames (the default setting), if no user authorization is required

Some IIS web servers however, support NTLM (Integrated Windows)
authentication, where valid CREDENTIALS are mandatory. In other words, a
83

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

none specification will not be supported by such IIS web servers. Therefore, in
this case, against each configured URLname, you will have to provide a valid
Username in the format: domainname\username, followed by a valid Password.
Please be sure to check if your web site requires HTTP authentication while
configuring this parameter. HTTP authentication typically involves a separate
pop-up window when you try to access the page. Many sites use HTTP POST for
obtaining the user name and password and validating the user login. In such
cases, the username and password have to be provided as part of the POST
information and NOT as part of the CREDENTIALS specification for the HTTP
test.

13. TIMEOUT - Here, specify the maximum duration (in seconds) for which the test

Outputs of the
test
Measurements
of the test

will wait for a response from the server. The default TIMEOUT period is 30
seconds.
One set of outputs for every URL being monitored

Measurement
Availability:

Measurement
Unit
Percent

Availability failures could be caused by
several factors such as the web server
process(es) being down, the web server
being misconfigured, a network failure,
etc. Temporary unavailability may also
occur if the web server is overloaded.
Availability is determined based on the
response code returned by the server.
A response code between 200 to 300
indicates that the server is available.

Secs

Response time being high denotes a
problem. Poor response times may be
due to the server being overloaded or
misconfigured. If the URL accessed
involves the generation of dynamic
content by the server, backend
problems (e.g., an overload at the
application server or a database failure)
can also result in an increase in
response time.

Percent

Failure to establish a TCP connection
may imply that either the web server
process is not up, or that the process is
not operating correctly. In some cases
of extreme overload, the failure to
establish a TCP connection may be a
transient condition. As the load
subsides,
the
server
may
start
functioning properly again.

This measurement
indicates whether the
server was able to respond
successfully to the query
made by the test.

Total response time:
This measurement
indicates the time taken by
the server to respond to
the requests it receives.

Tcp connection
availability:

Interpretation

This measure indicates
whether the test managed
to establish a TCP
connection to the server.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Tcp connect time:

S e r v e r s

Secs

Typically,
the
TCP
connection
establishment must be very small (of
the order of a few milliseconds). Since
TCP
connection
establishment
is
handled at the OS-level, rather than by
the application, an increase in this
value
signifies
a
system-level
bottleneck on the host that supports
the web server.

Secs

While the total response time may
depend on several factors, the server
response time is typically, a very good
indicator of a server bottleneck (e.g.,
because all the available server threads
or processes are in use).

Number

A value between 200 and 300 indicates
a good response. A 4xx value indicates
a problem with the requested content
(eg., page not found). A 5xx value
indicates a server error.

Kbytes

Typically the content length returned by
the server for a specific URL should be
the same across time. Any change in
this metric may indicate the need for
further investigation on the server side.

Percent

A value of 100% indicates that the
content returned by the test is valid. A
value of 0% indicates that the content
may not be valid. This capability for
content
validation
is
especially
important
for
multi-tier
web
applications. For example, a user may
not be able to login to the web site but
the server may reply back with a valid
HTML page where in the error message,
say, "Invalid Login" is reported. In this
case, the availability will be 100 %
(since we got a valid HTML response).
If the test is configured such that the
content parameter should exclude the
string "Invalid Login," in the above
scenario content validity would have a
value 0.

This measure quantifies
the time for establishing a
TCP connection to the web
server host.

Server response time:
This measure indicates the
time period between when
the connection was
established and when the
server sent back a HTTP
response header to the
client.
Response code:
The response code
returned by the server for
the simulated request
Content length:
The size of the content
returned by the server

Content validity:
This measure validates
whether the server was
successful in executing the
request made to it.

2.1.3.2

WL Security Test

This test reports security-related statistics for a WebLogic server. This test will work on WebLogic 7.x
and 8.0 only. While monitoring WebLogic 6.0, all the measures of this test will return 0.
85

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Purpose

Measures security statistics for a WebLogic server

Target of the
test

Any WebLogic managed server

Agent
deploying
test

An internal agent

the

Configurable
parameters for
the test

8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.

9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")

10. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of the
server.
This
parameter
can
be
changed
to
a
value
of
http://:. In this case, the test connects
to the WebLogic admin server to collect metrics pertaining to the managed
server (specified by the HOST and PORT). The URL setting provides the
administrator with the flexibility of determining the WebLogic monitoring
configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed to
the admin server, and it is up and running.

Outputs of the
test
Measurements
made by the

One set of results for every WebLogic server instance being monitored

Measurement
Unit

Measurement

Interpretation

M o n i t o r i n g

test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Invalid login attempts:
Returns the cumulative number
of invalid logins attempted on
this server.
Invalid users
water mark:

count

high

Attempts
Sec

Look for an unusual number of
invalid logins.

Number

Returns the high water mark of
the number of users with
outstanding
invalid
login
attempts for this server.
Current locked users:

Number

Returns the number of currently
locked users on this server.
Locked user logins:

Locked users cannot login to the
server. Hence, configure the
thresholds, so as to be alerted
when this value is greater than 0.

Number

Returns the cumulative number
of invalid logins attempted
during the last measurement
period on this server while the
user was locked.
Unlocked users:

Number

Returns the number of times a
user has been unlocked on this
server
during
the
last
measurement period.
Users lockedout:

Number

Returns the cumulative number
of user lockouts done on this
server
during
the
last
measurement period.

2.1.3.3

WebLogic JTA Test

This test reports transaction-related statistics for a WebLogic server.

Purpose

Reports transaction-related statistics for a WebLogic server

Target of the test

Any managed WebLogic server

Agent deploying the
test

An internal agent

M o n i t o r i n g

W e b L o g i c

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS
flag is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to
connect to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of
the server. This parameter can be changed to a value of
http://:. In this case, the test
connects to the WebLogic admin server to collect metrics pertaining to the
managed server (specified by the HOST and PORT). The URL setting
provides the administrator with the flexibility of determining the WebLogic
monitoring configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed
to the admin server, and it is up and running.
11. VERSION - The VERSION textbox indicates the version of the Weblogic
server to be managed. The default value is "none", in which case the test
auto-discovers the weblogic version. If the value of this parameter is not
"none", the test uses the value provided (e.g., 7.0) as the weblogic version
(i.e., it does not auto-discover the weblogic server version). This parameter
has been added to address cases when the eG agent is not able to discover
the WebLogic server version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done
using a Web archive file deployed on the WebLogic server (in which case,
HTTP/HTTPS is used by the server to connect to the server). If this flag is
set to No, the agent directly connects to the WebLogic server using the T3
protocol (no other file needs to be deployed on the WebLogic server for this
to work). Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only. Also, if the USEWARFILE parameter is set to No, make
sure that the ENCRYPTPASS parameter is set to No as well.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

When monitoring a WebLogic server deployed on a Unix platform
particularly, if the USEWARFILE parameter is set to No, you have to make
sure that the eG agent install user is added to the WebLogic users group.
13. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's
java archive (Jar) file. If the USEWARFILE flag is set to No, then the
weblogic.jar file specified here is used to connect to the corresponding
WebLogic server using the T3 protocol. Note that the T3 protocol-based support is
available for WebLogic servers ver.9 and ver. 10 only.

Outputs of the test
Measurements
made by the test

One set of results for every WebLogic server monitored

Measurement
Unit

Measurement
Total
transactions:

active

Interpretation

Number

This metric gives an idea of the
server load.

Trans/Sec

Typically,
the
abandoned
transaction rate should be low.

Trans/Sec

Rollbacks can occur due to
various reasons. Correlate the
rollbacks on the application
server with that on the database
to isolate the cause of the
rollbacks.

Returns the number of
active transactions on the
server
Transaction aborts:
Returns
the
rate
of
transactions
that
were
abandoned
Application rollbacks:
Returns
the
rate
of
transactions
that
were
rolled back due to an
application error
Resource rollbacks:

Trans/Sec

Returns
the
rate
of
transactions
that
were
rolled back due to a
resource error
System rollbacks:

Trans/Sec

Returns
the
rate
of
transactions
that
were
rolled back due to an
internal system error
Rollback timeouts:

Trans/Sec

Returns
the
rate
of
transactions
that
were
rolled back due to a
timeout expiration

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Commits:
Returns
the
rate
committed transactions

Trans/Sec
of

Heuristic transactions:

Trans/Sec

Returns
the
rate
of
transactions
that
completed with a heuristic
status
Total rollbacks:

Trans/Sec

Returns
the
rate
of
transactions
that
were
rolled back
Total transactions:

A high value (rate) here would
mean that more number of
transactions are being rolled
back.

Trans/Sec

Returns the total rate of
transactions
processed.
This total includes all
committed, rolled back and
heuristic
transaction
completions

2.1.3.4

WebLogic Servlets Test

This test periodically tracks the servlets invoked and reloaded, and measures the minimum,
maximum, and average response times of a specific server instance. Use the Click here hyperlink in the
test configuration page to configure the servlet groups that need to be monitored by the eG Enterprise
suite. By default, eG Enterprise system monitors only those servlets that are part of a group.

Purpose

To periodically track the servlets invoked and reloaded, and measure the
minimum, maximum, and average response times of a specific server instance

Target of the test

Any managed WebLogic server

Agent deploying the
test

An internal agent

M o n i t o r i n g

W e b L o g i c

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS
flag is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to
connect to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of
the server. This parameter can be changed to a value of
http://:. In this case, the test
connects to the WebLogic admin server to collect metrics pertaining to the
managed server (specified by the HOST and PORT). The URL setting
provides the administrator with the flexibility of determining the WebLogic
monitoring configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed
to the admin server, and it is up and running.
11. AUTODISCOVERY – By default, the eG suite allows administrators to
configure servlet groups using the eG administrative interface, and reports
metrics pertaining to every group so created. Accordingly, by default,
AUTODISCOVERY is set to NO. If you want servlets to be discovered and
monitored
automatically,
then
select
the
YES
option
against
AUTODISCOVERY. When this is done, the eG agent automatically discovers
all the servlets on the WebLogic server, and reports one set of measures for
every servlet hosted on the server.
12. VERSION - The VERSION textbox indicates the version of the Weblogic
server to be managed. The default value is "none", in which case the test
auto-discovers the weblogic version. If the value of this parameter is not
"none", the test uses the value provided (e.g., 7.0) as the weblogic version
(i.e., it does not auto-discover the weblogic server version). This parameter
has been added to address cases when the eG agent is not able to discover
the WebLogic server version.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

13. USEWARFILE - This flag indicates whether/not monitoring is to be done
using a Web archive file deployed on the WebLogic server (in which case,
HTTP/HTTPS is used by the server to connect to the server). If this flag is
set to No, the agent directly connects to the WebLogic server using the T3
protocol (no other file needs to be deployed on the WebLogic server for this
to work). Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only. Also, if the USEWARFILE parameter is set to No, make
sure that the ENCRYPTPASS parameter is set to No as well.
When monitoring a WebLogic server deployed on a Unix platform
particularly, if the USEWARFILE parameter is set to No, you have to make
sure that the eG agent install user is added to the WebLogic users group.
14. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's
java archive (Jar) file. If the USEWARFILE flag is set to No, then the
weblogic.jar file specified here is used to connect to the corresponding
WebLogic server using the T3 protocol. Note that the T3 protocol-based support is
available for WebLogic servers ver.9 and ver. 10 only.
15. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the
eG Enterprise suite embeds an optional detailed diagnostic capability. With
this capability, the eG agents can be configured to run detailed, more
elaborate tests as and when specific problems are detected. To enable the
detailed diagnosis capability of this test for a particular server, choose the
On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will
be available only if the following conditions are fulfilled:

Outputs of the test
Measurements
made by the test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for every servlet group configured

Measurement
Max execution time of
servlet:

Measurement
Unit
Number

The average duration for
which the single longest
invocation
of
all
the
servlets within a servlet
group
executed
since
creation
Min execution time of
servlet:

Secs

The average duration for
which the single shortest
invocation
of
all
the
servlets in a servlet group
executed since creation

Interpretation

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Invocation
servlet:

count

S e r v e r s

Number

The total number of times
the
servlets
within
a
servlet group were invoked

Reloads of servlet:

Comparing
this
value
across
servlets can provide an indication of
the relative popularity of the
servlets. An administrator can use
information about invocations to
determine the servlet(s), by tuning
which the performance of the
service
can
be
significantly
improved.

Number

The total number of times
for which the servlets
within a servlet group were
reloaded
Avg
execution
servlet:

Secs

The average of response
time of the servlets in a
servlet group

This
measure
indicates
which
servlet(s)
are
providing
slow
response. An increased execution
time can be attributed to poor
design of the servlet code, slow
database access or non-optimal
queries.

The detailed diagnosis of the all the above measures, if enabled, reveals the maximum execution
time, minimum execution time, invocation count, reload count, and average execution time for every
servlet in the configured servlet groups. Note that the detailed diagnosis information will not be available if the
AUTODISCOVERY parameter is set to ‘Yes’.

Figure 2.16: The detailed diagnosis of the Max execution time measure

M o n i t o r i n g

2.1.3.5

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

WebLogic Server Test

This test reports key run-time statistics pertaining to the instances of a WebLogic server.

Purpose

Reports key run-time statistics pertaining to the instances of a WebLogic server

Target of the test

Any managed WebLogic server

Agent deploying the
test

An internal agent

M o n i t o r i n g

W e b L o g i c

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

1. TESTPERIOD - How often should the test be executed
2. HOST – The IP address of the WebLogic server
3. PORT – The port number of the WebLogic server
4. USER – The admin user name of the WebLogic server being monitored.
5. PASSWORD – The password of the specified admin user
6. CONFIRM PASSWORD – Confirm the password by retyping it here.
7. ENCRYPTPASS - If the specified password needs to be encrypted, set the
ENCRYPTPASS flag to YES. Otherwise, set it to NO. By default, the YES option
will be selected.

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS
flag is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to
connect to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of
the server. This parameter can be changed to a value of
http://:. In this case, the test
connects to the WebLogic admin server to collect metrics pertaining to the
managed server (specified by the HOST and PORT). The URL setting
provides the administrator with the flexibility of determining the WebLogic
monitoring configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed
to the admin server, and it is up and running.
11. VERSION - The VERSION textbox indicates the version of the Weblogic
server to be managed. The default value is "none", in which case the test
auto-discovers the weblogic version. If the value of this parameter is not
"none", the test uses the value provided (e.g., 7.0) as the weblogic version
(i.e., it does not auto-discover the weblogic server version). This parameter
has been added to address cases when the eG agent is not able to discover
the WebLogic server version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done
using a Web archive file deployed on the WebLogic server (in which case,
HTTP/HTTPS is used by the server to connect to the server). If this flag is
set to No, the agent directly connects to the WebLogic server using the T3
protocol (no other file needs to be deployed on the WebLogic server for this
to work). Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only. Also, if the USEWARFILE parameter is set to No, make
sure that the ENCRYPTPASS parameter is set to No as well.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

When monitoring a WebLogic server deployed on a Unix platform
particularly, if the USEWARFILE parameter is set to No, you have to make
sure that the eG agent install user is added to the WebLogic users group.
13. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's
java archive (Jar) file. If the USEWARFILE flag is set to No, then the
weblogic.jar file specified here is used to connect to the corresponding
WebLogic server using the T3 protocol. Note that the T3 protocol-based support is
available for WebLogic servers ver.9 and ver. 10 only.

Outputs of the test
Measurements
made by the test

One set of results for every WebLogic server being monitored

Measurement
Unit

Measurement
Server availability:

Percent

Indicates the state of the
WebLogic server instance.

Interpretation
A server instance can assume
any of the following states:
State

Description

ACTIVE_LATER

Indicates that
MaxRestart
restart
attempts have
been made in
current
RestartInterval
,
and
Node
Manager
will
attempt
additional
restarts

FAILED

A
critical
subsystem
is
not functioning

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

FAILED_NOT_R
ESTARTABLE

Indicates that
the
Managed
Server
has
failed or was
killed by Node
Manager as a
result of the
Managed
Server's
AutoKillIfFailed
attribute being
set to True,
but
Node
Manager
cannot restart
the
Managed
Server because
its AutoRestart
attribute is set
to False.

FAILED_RESTA
RTING

Indicates that
Node Manager
is
currently
restarting
a
failed Managed
Server

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

RESUMING

The server is
transitioning
from
the
STANDBY state
to RUNNING.

RUNNING

The server can
receive
and
process
requests from
external clients
as
well
as
administrative
requests.

SHUTDOWN

The server is
configured but
inactive.

SHUTDOWN_I
N_PROCESS

Indicates that
the shutdown
is in progress

SHUTDOWN_P
ENDING

Indicates that
a
shutdown
request
has
been sent, but
the
actual
shutdown
process is yet
to begin

SHUTTING_DO
WN

The server is
transitioning
from either the
RUNNING
or
STANDBY state
to SHUTDOWN.

STANDBY

The server can
receive
and
process
only
administrative
requests.

STARTING

The server is
initializing
all
it's
subsystems.

SUSPENDING

The server is
transitioning
from either the
SHUTDOWN or
RUNNING state
to STANDBY.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

UNKNOWN

The state of
the
server
cannot
be
determined,
perhaps
because
it
cannot
be
contacted.

If the state of the server
instance
is
STARTING,
RUNNING, or RESUMING, then
the value of this measure will be
100. For any other state, the
value of this measure will be 0.
Current sockets count:

Number

Indicates the number of
sockets registered for socket
muxing
on
this
server
instance.
Sockets opened:

Number

Indicates the total number of
registrations
for
socket
muxing on this server.

2.1.3.6

WebLogic Web Applications Test

This test automatically discovers all the Web application components deployed on the WebLogic
server, and reports real-time performance data pertaining to each of the components.

Purpose

Reports real-time performance data pertaining to each of the Web application
components

Target of the test

Any managed WebLogic server

Agent deploying the
test

An internal agent

M o n i t o r i n g

W e b L o g i c

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed
to the admin server, and it is up and running.
11. VERSION - The VERSION textbox indicates the version of the Weblogic
server to be managed. The default value is "none", in which case the test
auto-discovers the weblogic version. If the value of this parameter is not
"none", the test uses the value provided (e.g., 7.0) as the weblogic version
(i.e., it does not auto-discover the weblogic server version). This parameter
has been added to address cases when the eG agent is not able to discover
the WebLogic server version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done
using a Web archive file deployed on the WebLogic server (in which case,
HTTP/HTTPS is used by the server to connect to the server). If this flag is
set to No, the agent directly connects to the WebLogic server using the T3
protocol (no other file needs to be deployed on the WebLogic server for this
to work). Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only. Also, if the USEWARFILE parameter is set to No, make
sure that the ENCRYPTPASS parameter is set to No as well.

100

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

When monitoring a WebLogic server deployed on a Unix platform
particularly, if the USEWARFILE parameter is set to No, you have to make
sure that the eG agent install user is added to the WebLogic users group.
13. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's
java archive (Jar) file. If the USEWARFILE flag is set to No, then the
weblogic.jar file specified here is used to connect to the corresponding
WebLogic server using the T3 protocol. Note that the T3 protocol-based support is
available for WebLogic servers ver.9 and ver. 10 only.

Outputs of the test
Measurements
made by the test

One set of results for every Web application discovered on the WebLogic server
being monitored

Measurement
Unit

Measurement
Sessions open current:

Interpretation

Number

Indicates the total number of
open
sessions
in
this
component currently.
Sessions open high water
mark:

Number

Returns the high water mark
of the total number of open
sessions in this component.
Sessions open total:

Number

Returns the total number of
open
sessions
in
this
component since the last
measurement period.

Sessions invalid time:

This measure is indicative of the
workload on the application
component. By observing the
variations to this measure over
time, you can determine usage
trends such as the time of day
when an application is getting
the most amount of traffic.

Secs

Returns
the
invalidation
check
timer
interval
configured for http sessions.

2.1.3.7

WebLogic Queues Test

A JMS queue represents the point-to-point (PTP) messaging model, which enables one application to
send a message to another. PTP messaging applications send and receive messages using named
queues. A queue sender (producer) sends a message to a specific queue. A queue receiver
(consumer) receives messages from a specific queue.
This test auto-discovers the queues on a WebLogic server, and monitors each queue for the size,
number, and type of messages it holds, so that impending overloads and probable delivery
bottlenecks can be proactively isolated and corrected.

101

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Purpose

Auto-discovers the queues on a WebLogic server, and monitors each queue for
the size, number, and type of messages it holds, so that impending overloads
and probable delivery bottlenecks can be proactively isolated and corrected

Target of the test

Any managed WebLogic server

Agent deploying the
test

An internal agent

102

M o n i t o r i n g

W e b L o g i c

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

103

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

When monitoring a WebLogic server deployed on a Unix platform
particularly, if the USEWARFILE parameter is set to No, you have to make
sure that the eG agent install user is added to the WebLogic users group.
13. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's
java archive (Jar) file. If the USEWARFILE flag is set to No, then the
weblogic.jar file specified here is used to connect to the corresponding
WebLogic server using the T3 protocol. Note that the T3 protocol-based support is
available for WebLogic servers ver.9 and ver. 10 only.

Outputs of the test
Measurements
made by the test

One set of results for every queue auto-discovered on the monitored WebLogic
server

Measurement
Unit

Measurement
Messages count:

Number

This count does not include the
messages that are pending.

Number

A message is considered to be in
pending state when it is:

Indicates the current number
of messages in this queue.

Messages pending count:

Interpretation

Indicates the number of
pending messages in this
queue.



sent in a transaction but
not committed.



received
and
acknowledged

not



received

not

and

committed

104



subject to a redelivery
delay (as of WebLogic
JMS 6.1 or later)



subject to a delivery
time (as of WebLogic
JMS 6.1 or later)

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

While momentary spikes in the
number of pending messages in
a queue is normal, if the number
is allowed to grow consistently
over time, it is bound to increase
the total number of messages in
the queue. Typically, the sum of
the values of the Messages count
and the Messages pending count
measures
equals
the
total
number of messages in the
queue. If this sum is equal to or
is very close to the Messages
Maximum setting for the quota
resource that is mapped to this
queue, it implies that the queue
has filled up or is rapidly filling
up with messages and cannot
handle any more. When this
happens, JMS prevents further
sends
with
a
ResourceAllocationException.
Furthermore, such quota failures
will force multiple producers to
contend for space in the queue,
thereby degrading application
performance. To avoid this, you
can
do
one/more
of
the
following:



Increase the Messages
Maximum setting of the
quota resource mapped
to the queue;



If a quota has not been
configured for the queue,
then increase the quota
of the JMS server where
the queue is deployed;

105

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



Regulate the flow of
messages into the queue
using one/more of the
following configurations:

Blocking
senders
during
quota
conditions: The Send
Timeout
provides

feature
more

control over message
send operations by
giving
message
producers the option
of waiting a specified
length of time until
space
available

becomes
on
a

destination.

Specifying a Blocking
Send Policy on JMS
Servers
Blocking

The
Send

policies enable you
to define the JMS
server’s
blocking
behavior on whether
to deliver
messages

smaller
before

larger ones when
multiple
message
producers
are
competing for space
on a destination that
has
exceeded
its
message quota.

106

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Using
the
Flow
Control feature: With
the
Flow
Control
feature,
you
can
direct a JMS server
or destination to slow
down
producers

message
when it

determines that it is
becoming
overloaded.
Specifically,

when

either a JMS server
or it’s destinations
exceeds its specified
byte
or
message
threshold, it becomes
armed and instructs
producers to limit
their message flow
(messages
per
second).
Producers
will
limit
production

their
rate

based on a set of
flow
control
attributes configured
for producers via the
JMS
connection
factory. Starting at a
specified
flow
maximum number of
messages,
a
producer
evaluates
whether
the
server/destination is
still
armed
at
prescribed intervals
(for example, every
10 seconds for 60
seconds).

107

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

If at each interval,
the
server/destination is
still armed, then the
producer
continues
to move its rate
down
to
its
prescribed
flow
minimum amount. As
producers
slow
themselves
down,
the
threshold
condition
gradually
corrects itself until
the
server/destination is
unarmed.
At
this
point, a producer is
allowed to increase
its production rate,
but not necessarily to
the
maximum
possible rate. In fact,
its
message
flow
continues
to
be
controlled
(even
though
the
server/destination is
no longer armed)
until it reaches its
prescribed
flow
maximum, at which
point it is no longer
flow controlled.

By tuning Message
Performance
Preference:
Messaging
Performance
Preference

The

tuning

option
on
JMS
destinations enables
you to control how
long a destination
should wait (if at all)
before creating full
batches of available
messages
for
delivery
consumers.

108

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

At
the
minimum
value, batching is
disabled.
Tuning
above the default
value increases the
amount of time a
destination is willing
to
wait
before
batching
available
messages.
The
maximum message
count of a full batch
is controlled by the
JMS
connection
factory’s
Messages
Maximum
per
Session setting. It
may
take
some
experimentation
to
find out which value
works best for your
system. For example,
if you have a queue
with
many
concurrent message
consumers,
by
selecting
the
Administration
Console’s
Do
Not
Batch
Messages
value (or specifying
“0”
on
the
DestinationBean
MBean), the queue
will
make
every
effort to promptly
push messages out
to its consumers as
soon as they are
available.

109

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Conversely, if you
have a queue with
only one message
consumer that does
not
require
fast
response times, by
selecting
the
console’s
High
Waiting Threshold for
Message Batc hing
value (or specifying
“100”
on
the
DestinationBean
MBean),
you
can
ensure
that
the
queue only pushes
messages to that
consumer in batches.
Bytes count:

Indicates the current size of
the message that is stored in
the queue destination in
bytes.

110

This count does not include the
pending bytes.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Bytes pending count:

Indicates the current size of
the pending message that is
stored
in
the
queue
destination in bytes.

111

While momentary spikes in the
size of pending messages in a
queue is acceptable, if the size is
allowed to grow consistently
over time, it is bound to increase
the total size of all messages in
the queue. Typically, the sum of
the
values
of
the
BytesCurrentCount
and
the
BytesPendingCount
measures
indicates the total size of all
messages in the queue. If this
sum is equal to or is very close
to the Bytes Maximum setting
for the quota resource that is
mapped to this queue, it implies
that the queue has filled up or is
rapidly filling up with messages
and cannot handle any more.
When
this
happens,
JMS
prevents further sends with a
ResourceAllocationException.
Furthermore, such quota failures
will force multiple producers to
contend for space in the queue,
thereby degrading application
performance. To avoid this, you
can
do
one/more
of
the
following:

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



Increase
the
Bytes
Maximum setting of the
quota resource mapped
to the queue;



If a quota has not been
configured for the queue,
then increase the quota
of the JMS server where
the queue is deployed;



Regulate

the

flow

messages into the queue
using one/more of the
following configurations:

Blocking
senders
during
quota
conditions: The Send
Timeout
provides

feature
more

control over message
send operations by
giving
message
producers the option
of waiting a specified
length of time until
space
available

becomes
on
a

destination.

Specifying a Blocking
Send Policy on JMS
Servers
Blocking

The
Send

policies enable you
to define the JMS
server’s
blocking
behavior on whether
to deliver
messages

smaller
before

larger ones when
multiple
message
producers
are
competing for space
on a destination that
has
exceeded
its
message quota.
112

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Using
the
Flow
Control feature:

With the Flow Control
feature,
you
can
direct a JMS server
or destination to slow
down
message
producers when it
determines that it is
becoming
overloaded.
Specifically,
when
either a JMS server
or it’s destinations
exceeds its specified
byte
or
message
threshold, it becomes
armed and instructs
producers to limit
their message
(messages

flow
per

second).
Producers
will
limit
their
production
rate
based on a set of
flow
control
attributes configured
for producers via the
JMS
connection
factory. Starting at a
specified
flow
maximum number of
messages,
a
producer
whether

evaluates
the

server/destination is
still
armed
at
prescribed intervals
(for example, every
10 seconds for 60
seconds).

113

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

If at each interval,
the
server/des
tination
is
still
armed,
then
the
producer
continues
to move its rate
down
to
its
prescribed
flow
minimum amount. As
producers
slow
themselves
down,
the
threshold
condition
gradually
corrects itself until
the
server/destination is
unarmed.
At
this
point, a producer is
allowed t o increase
its production rate,
but not necessarily to
the
maximum
possible rate. In fact,
its
message
flow
continues
to
be
controlled
(even
though
the
server/destination is
no longer armed)
until it reaches its
prescribed
flow
maximum, at which
point it is no longer
flow controlled.

By
Tuning
the
MessageMaximum
configuration:
WebLogic
JMS
pipelines
messages
that are delivered to
asynchronous
consumers
(otherwise known as
message listeners) or
prefetch-enabled
synchronous
consumers.

114

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

The
messages
backlog (the size of
the
pipeline)
between
the
JMS
server and the client
is
tunable
by
configuring
the
MessagesMaximum
setting
on
the
connection
factory.
In
some
circumstances,
tuning this setting
may
improve
performance
dramatically, such as
when
the
JMS
application
defers
acknowledges
or
commits.
In
this
case, BEA suggests
setting
the
MessagesMaximum
value to: 2 * (ack or
commit interval) + 1.
For example, if the
JMS
application
acknowledges
50
messages at a time,
set
the
MessagesMaximum
value to 101. You
may also need to
configure WebLogic
clients in addition to
the WebLogic Server
instance,
when
sending
and
receiving
large
messages.
By
compressing
messages: You may
improve
the
performance
of
sending
large
messages
traveling
across
JVM
boundaries and help
conserve disk space
by
specifying
the
automatic

115

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

compression of any
messages
that
exceed
specified

a
userthreshold

size.
Message
compression can help
reduce
bottlenecks

network
by

automatically
reducing the size of
messages
across

sent
network

wires. Compressing
messages can also
conserve disk space
when
storing
persistent messages
in file stores or
databases.

By
paging
out
messages: With the
message
paging
feature, JMS servers
automatically
attempt to free up
virtual
memory
during peak message
load periods. This
feature can greatly
benefit applications
with large message
spaces.
By
tuning
the
Message Buffer Size:
The Message Buffer
Size option specifies
the
amount
of
memory that will be
used
to
store
message bodies in
memory before they
are paged out to
disk.

116

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

The default value of
Message Buffer Size
is
approximately
one-third
of
the
maximum heap size
for the JVM, or a
maximum
of
512
megabytes.
The
larger this parameter
is set, the more
memory
JMS
will
consume when many
messages are waiting
on queues or topics.
Once this threshold
is crossed, JMS may
write message bodies
to
the
directory
specified
by
the
Paging
Directory
option in an effort to
reduce
memory
usage
below
this
threshold.
Messages deleted count:

Number

Indicates the number of
messages that have been
deleted from this queue.

Messages moved count:

Number

Indicates the number of
messages that have been
moved from one queue
destination to the other.
Consumers count:

Number

Indicates the current number
of consumers accessing the
queue destination.

117

While
you
can
design
a
QueueBrowser on your JMS
server to view and delete
specific queue messages, some
messages
are
automatically
deleted by the server. For
instance,
one-way
messages
that exceed quota are silently
deleted
without
immediately
throwing exceptions back to the
client.

M o n i t o r i n g

2.1.3.8

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

WebLogic Topics Test

The publish/subscribe (pub/sub) messaging model enables an application to send a message to
multiple applications. Pub/sub messaging applications send and receive messages by subscribing to a
topic. A topic publisher (producer) sends messages to a specific topic. A topic subscriber (consumer)
retrieves messages from a specific topic.
This test auto-discovers the topics on a WebLogic server, and monitors each topic for the size,
number, and type of messages it holds, so that impending overloads and probable delivery
bottlenecks can be proactively isolated and corrected.

Purpose

Auto-discovers the topics on a WebLogic server, and monitors each topic for the
size, number, and type of messages it holds, so that impending overloads and
probable delivery bottlenecks can be proactively isolated and corrected

Target of the test

Any managed WebLogic server

Agent deploying the
test

An internal agent

118

M o n i t o r i n g

W e b L o g i c

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS
flag is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to
connect to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of
the server. This parameter can be changed to a value of
http://:. In this case, the test
connects to the WebLogic admin server to collect metrics pertaining to the
managed server (specified by the HOST and PORT). The URL setting
provides the administrator with the flexibility of determining the WebLogic
monitoring configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed
to the admin server, and it is up and running.
11. VERSION - The VERSION textbox indicates the version of the Weblogic
server to be managed. The default value is "none", in which case the test
auto-discovers the weblogic version. If the value of this parameter is not
"none", the test uses the value provided (e.g., 7.0) as the weblogic version
(i.e., it does not auto-discover the weblogic server version). This parameter
has been added to address cases when the eG agent is not able to discover
the WebLogic server version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done
using a Web archive file deployed on the WebLogic server (in which case,
HTTP/HTTPS is used by the server to connect to the server). If this flag is
set to No, the agent directly connects to the WebLogic server using the T3
protocol (no other file needs to be deployed on the WebLogic server for this
to work). Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only. Also, if the USEWARFILE parameter is set to No, make
sure that the ENCRYPTPASS parameter is set to No as well.

119

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

When monitoring a WebLogic server deployed on a Unix platform
particularly, if the USEWARFILE parameter is set to No, you have to make
sure that the eG agent install user is added to the WebLogic users group.
13. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's
java archive (Jar) file. If the USEWARFILE flag is set to No, then the
weblogic.jar file specified here is used to connect to the corresponding
WebLogic server using the T3 protocol. Note that the T3 protocol-based support is
available for WebLogic servers ver.9 and ver. 10 only.

Outputs of the test
Measurements
made by the test

One set of results for every topic auto-discovered on the monitored WebLogic
server

Measurement
Unit

Measurement
Messages count:

Number

This count does not include the
messages that are pending.

Number

While momentary spikes in the
number of pending messages in
a topic is normal, if the number
is allowed to grow consistently
over time, it is bound to increase
the total number of messages in
the topic. Typically, the sum of
the
values
of
the
MessagesCurrentCount and the
MessagesPendingCount
measures
equals
the
total
number of messages in the
topic. If this sum is equal to or is
very close to the Messages
Maximum setting for the quota
resource that is mapped to this
topic, it implies that the topic
has filled up or is rapidly filling
up with messages and cannot
handle any more. When this
happens, JMS prevents further
sends
with
a
ResourceAllocationException.

Indicates the current number
of messages in this topic.

Messages pending count:

Interpretation

Indicates the number of
pending messages in this
topic.

Furthermore, such quota failures
will force multiple producers to
contend for space in the topic,
thereby degrading application
performance. To avoid this, you
can
do
one/more
of
the
following:

120

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



Increase
Maximum

the
Messages
setting of the

quota resource mapped to
the topic;



If a quota has not been
configured for the topic, then
increase the quota of the
JMS server where the topic is
deployed;



Regulate

the

flow

messages into the topic
using
one/more
of
the
following configurations:

Blocking senders during
quota conditions: The
Send Timeout feature
provides more control
over
message
send
operations
by
giving
message producers the
option
of
waiting
a
specified length of time
until
space
becomes
available
on
a
destination.

Specifying a
Send Policy

Blocking
on JMS

Servers : The Blocking
Send policies enable you
to
define
server’s

the
JMS
blocking

behavior on whether to
deliver smaller messages
before larger ones when
multiple
message
producers are competing
for
space
on
a
destination
that
has
exceeded its message
quota.

121

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Using the Flow Control
feature: With the Flow
Control feature, you can
direct a JMS server or
destination to slow down
message producers when
it determines that it is
becoming
overloaded.
Specifically, when either
a JMS server or it’s
destinations exceeds its
specified
byte
or
message
becomes

threshold, it
armed
and

instructs producers to
limit their message flow
(messages per second).
Producers will limit their
production rate based on
a set of flow control
attributes configured for
producers via the JMS
connection
factory.
Starting at a specified
flow maximum number
of messages, a producer
evaluates whether the
server/destination is still
armed
at
prescribed
intervals (for example,
every 10 seconds for 60
seconds). If at each
interval,
the
server/destination is still
armed,
producer

then
the
continues to

move its rate down to its
prescribed flow minimum
amount.

122

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

As
producers
slow
themselves down, the
threshold
condition
gradually corrects itself
until
server/destination

the
is

unarmed. At this point, a
producer is allowed to
increase its production
rate, but not necessarily
to the maximum possible
rate. In fact, its message
flow continues to be
controlled (even though
the server/destination is
no longer armed) until it
reaches its prescribed
flow maximum, at which
point it is no longer flow
controlled.
By
tuning
Message
Performance Preference:
The
Messaging
Performance Preference
tuning option on JMS
destinations enables you
to control how long a
destination should wait
(if at all) before creating
full batches of available
messages for delivery to
consumers.
At
the
minimum value, batching
is disabled. Tuning above
the
default
value
increases the amount of
time a destination is
willing to
batching

wait before
available

messages. The maximum
message count of a full
batch is controlled by the
JMS connection factory’s
Messages Maximum per
Session setting.

123

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

It
may
take
some
experimentation to find
out which value works
best for your system. For
example, if you have a
topic
with
many
concurrent
message
consumers, by selecting
the
Administration
Console’s Do Not Batch
Messages
specifying

value
“0” on

(or
the

DestinationBean MBean),
the topic will make every
effort to promptly push
messages out to its
consumers as soon as
they
are
available.
Conversely, if you have a
topic with only one
message consumer that
does not require fast
response
selecting

times,
by
the console’s

High Waiting Threshold
for Message Batching
value
“100”

(or
on

specifying
the

DestinationBean MBean),
you can ensure that the
topic
only
pushes
messages
to
that
consumer in batches.
Messages moved count:

Number

Indicates the number of
messages that have been
moved
from
this
topic
destination to another.
Bytes count:

Indicates the current size of
the message that is stored in
the topic destination in
bytes.

124

This count does not include the
pending bytes.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Bytes pending count:

Indicates the current size of
the pending message that is
stored
in
the
topic
destination in bytes.

While momentary spikes in the
size of pending messages in a
topic is acceptable, if the size is
allowed to grow consistently
over time, it is bound to increase
the total size of all messages in
the topic. Typically, the sum of
the
values
of
the
BytesCurrentCount
and
the
BytesPendingCount
measures
indicates the total size of all
messages in the topic. If this
sum is equal to or is very close
to the Bytes Maximum setting
for the quota resource that is
mapped to this topic, it implies
that the topic has filled up or is
rapidly filling up with messages
and cannot handle any more.
When
this
happens,
JMS
prevents further sends with a
ResourceAllocationException.
Furthermore, such quota failures
will force multiple producers to
contend for space in the topic,
thereby degrading application
performance. To avoid this, you
can
do
one/more
of
the
following:



Increase the Bytes Maximum
setting of the quota resource
mapped to the topic;



If a quota has not been
configured for the topic, then
increase the quota of the
JMS server where the topic is
deployed;



Regulate
messages

the
into

flow
of
the topic

using
one/more
of
the
following configurations:

125

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

o Blocking senders during
quota

conditions:

Send Timeout
provides more

The

feature
control

over
message
operations
by

send
giving

message producers the
option
of
waiting
a
specified length of time
until
space
becomes
available
destination.

o Specifying

a Blocking
Send Policy on JMS
Servers : The Blocking
Send policies enable you
to
define
the
JMS
server’s
blocking
behavior on whether to
deliver smaller messages
before larger ones when
multiple
message
producers are competing
for
space
on
destination
that
exceeded
quota.

its

a
has

message

o Using the Flow Control
feature: With the Flow
Control feature, you can
direct a JMS server or
destination to slow down
message producers when
it determines that it is
becoming overloaded.

126

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Specifically, when either a
JMS
server
or
it’s
destinations
exceeds
its
specified byte or message
threshold,
it
armed
and

becomes
instructs

producers to limit their
message flow (messages
per second). Producers will
limit their production rate
based on a set of flow
control attributes configured
for producers via the JMS
connection factory. Starting
at
a
specified
maximum
number
messages,
evaluates

flow
of

a
producer
whether
the

server/destination is still
armed
at
prescribed
intervals
(for
example,
every 10 seconds for 60
seconds).
interval,

each
the

server/destination is still
armed, then the producer
continues to move its rate
down to its prescribed flow
minimum
amount.
As
producers slow themselves
down,
the
threshold
condition gradually corrects
itself
until
server/destination

the
is

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

o By

Tuning
MessageMaximum

the

configuration: WebLogic
JMS pipelines messages
that are delivered to
asynchronous consumers
(otherwise
known
message listeners)

as
or

prefetch-enabled
synchronous consumers.
The messages backlog
(the size of the pipeline)
between the JMS server
and the client is tunable
by
configuring
MessagesMaximum

the

setting on the connection
factory.
In
some
circumstances,
tuning
this setting may improve
performance
dramatically,

such

when the JMS application
defers acknowledges or
commits. In this case,
BEA suggests setting the
MessagesMaximum value
to: 2 * (ack or commit
interval)
example,

+
if

1.
the

For
JMS

application acknowledges
50 messages at a time,
set
the
MessagesMaximum value
to 101. You may also
need
to
configure
WebLogic
clients
in
addition to the WebLogic
Server instance, when
sending and receiving
large messages.

128

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

o By
messages:

compressing
You
may

improve the performance
of
sending
large
messages
across JVM

traveling
boundaries

and help conserve disk
space by specifying the
automatic
compression
of any messages that
exceed a user-specified
threshold size. Message
compression
reduce

can help
network

bottlenecks
automatically

by
reducing

the size of messages
sent
across
network
wires.
messages

Compressing
can
also

conserve
disk
space
when storing persistent
messages in file stores or
databases.

o By paging out messages:
With the message paging
feature,
JMS
servers
automatically attempt to
free up virtual memory
during peak message
load periods. This feature
can
greatly
benefit
applications with large
message spaces.

129

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

o By tuning the Message
Buffer Size: The Message
Buffer
Size
option
specifies the amount of
memory that will be used
to store message bodies
in memory before they
are paged out to disk.
The default value of
Message Buffer Size is
approximately one-third
of the maximum heap
size for the JVM, or a
maximum
of
512
megabytes. The larger
this parameter is set, the
more memory JMS will
consume when many
messages are waiting on
topics or topics. Once
this threshold is crossed,
JMS may write message
bodies to the directory
specified by the Paging
Directory option in an
effort to reduce memory
usage
below
threshold.
Consumers count:

this

Number

Indicates the current number
of consumers accessing the
topic destination.
Messages deleted count:

Number

Indicates the number of
messages that have been
deleted
from
the
topic
destination.

130

M o n i t o r i n g

2.1.3.9

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

WebLogic JMS Test

This test extracts performance statistics pertaining to the Java Message Service (JMS) provided by the
WebLogic server. This test is disabled by default. To enable the test, go to the ENABLE / DISABLE TESTS
page using the menu sequence : Agents -> Tests -> Enable/Disable, pick WebLogic as the Component
type, Performance as the Test type, choose this test from the DISABLED TESTS list, and click on the >>
button to move the test to the ENABLED TESTS list. Finally, click the Update button.

Purpose

Generates performance statistics pertaining to the Java Message Service (JMS)
provided by the WebLogic server

Target of the test

Any managed WebLogic server

Agent deploying the
test

An internal agent

131

M o n i t o r i n g

W e b L o g i c

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

132

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

When monitoring a WebLogic server deployed on a Unix platform
particularly, if the USEWARFILE parameter is set to No, you have to make
sure that the eG agent install user is added to the WebLogic users group.
13. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's
java archive (Jar) file. If the USEWARFILE flag is set to No, then the
weblogic.jar file specified here is used to connect to the corresponding
WebLogic server using the T3 protocol. Note that the T3 protocol-based support is
available for WebLogic servers ver.9 and ver. 10 only.

Outputs of the test
Measurements
made by the test

One set of results for every WebLogic server being monitored

Measurement
Data received:

Measuremen
t Unit
KB/Sec

Returns the number of
bytes received on this JMS
server since the last reset
Destination count high
water mark:

Number

Returns the peak number
of destinations on this JMS
server since the last reset
Session pool count:

Number

Returns
the
current
number of session pools
instantiated on this JMS
server
Session pool count high
water mark:

Number

Returns the peak number
of
session
pools
instantiated on this JMS
server since the last reset
Message received:

Msgs/Sec

Returns the number of
messages received on this
destination since the last
reset
Current data count:

Returns
the
current
number of bytes stored on
this JMS server. This does
not include the pending
bytes.

133

Interpretation
This is an indicator of the workload
on the JMS server.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Data pending count:

Returns
the
current
number of bytes pending
(unacknowledged
or
uncommitted) stored on
this JMS server. Pending
bytes are over and above
the current number of
bytes.
Data count high water
mark:

Returns the peak number
of bytes stored in the JMS
server since the last reset

Current messages:

Number

Returns
the
current
number
of
messages
stored on this JMS server.
This does not include the
pending messages.
Pending messages:

Number

Returns
the
current
number
of
messages
pending (unacknowledged
or uncommitted) stored on
this JMS server. Pending
messages are over and
above the current number
of messages.
Messages count
water mark:

high

Ideally, the count of
messages should be low.

pending

Number

Returns the peak number
of messages stored in the
JMS server since the last
reset
Destination
count:

current

Number

Returns
the
current
number of destinations for
this JMS server

2.1.3.10

WebLogic Clusters Test

This test extracts cluster related statistics from a managed WebLogic server that is part of a cluster.
Server instances in a cluster communicate with each other using multicast—multicasts help the server
134

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

instances in a cluster announce their services, and issue periodic heartbeats that indicate continued
availability. This test is disabled by default. To enable the test, go to the ENABLE / DISABLE TESTS page
using the menu sequence : Agents -> Tests -> Enable/Disable, pick WebLogic as the Component type,
Performance as the Test type, choose this test from the DISABLED TESTS list, and click on the >> button to
move the test to the ENABLED TESTS list. Finally, click the Update button.

Purpose

To generate cluster-related measures from a managed WebLogic server that is
part of a cluster

Target of the test

Any managed WebLogic server that is part of a cluster

Agent deploying the
test

An internal agent

135

M o n i t o r i n g

W e b L o g i c

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

11. VERSION - The VERSION textbox indicates the version of the Weblogic
server to be managed. The default value is "none", in which case the test
auto-discovers the weblogic version. If the value of this parameter is not
"none", the test uses the value provided (e.g., 7.0) as the weblogic version
(i.e., it does not auto-discover the weblogic server version). This parameter
has been added to address cases when the eG agent is not able to discover
the WebLogic server version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done
using a Web archive file deployed on the WebLogic server (in which case,
HTTP/HTTPS is used by the server to connect to the server). If this flag is
set to No, the agent directly connects to the WebLogic server using the T3
protocol (no other file needs to be deployed on the WebLogic server for this
to work). Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only. Also, if the USEWARFILE parameter is set to No, make
sure that the ENCRYPTPASS parameter is set to No as well.

136

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

When monitoring a WebLogic server deployed on a Unix platform
particularly, if the USEWARFILE parameter is set to No, you have to make
sure that the eG agent install user is added to the WebLogic users group.
13. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's
java archive (Jar) file. If the USEWARFILE flag is set to No, then the
weblogic.jar file specified here is used to connect to the corresponding
WebLogic server using the T3 protocol. Note that the T3 protocol-based support is
available for WebLogic servers ver.9 and ver. 10 only.

Outputs of the test
Measurements
made by the test

One set of results for every WebLogic server monitored

Measurement
Alive servers:

Measurement
Unit
Number

Number of servers in the
clusters that are running
currently
Fragments sent:
The rate of multicast
fragments sent from this
server into the cluster
Fragments received:
Returns
the
rate
of
multicast
messages
received on this server
from the cluster
Fragments dropped:
Indicates
the
rate
of
fragments that originated
in foreign domains/clusters
that
use
the
same
multicast address
Messages lost:

Fragments/
Sec

Msgs/Sec

Returns the rate at which
incoming
multicast
messages that were lost
Request resends:

Reqs/sec

Returns the rate of statedelta messages that had to
be
resent
because
a
receiving server in the
cluster missed a message

137

Interpretation
Ideally this number must be equal
to the actual number of servers in
the cluster.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Primary count:

S e r v e r s

Number

Returns the number of
objects that the local
server hosts as primaries

2.1.3.11

File Descriptors Test

A file descriptor is a handle created by a process when a file is opened. A new descriptor is created
each time the file is opened. The File Descriptor test monitors the descriptors created by an
application. This test is disabled by default. To enable the test, go to the ENABLE / DISABLE TESTS page
using the menu sequence : Agents -> Tests -> Enable/Disable, pick WebLogic as the Component type,
Performance as the Test type, choose the test from the DISABLED TESTS list, and click on the >> button to
move the test to the ENABLED TESTS list. Finally, click the Update button. only.

Purpose

Monitors the descriptors created by an application

Target of the test

Any managed WebLogic server

Agent deploying the
test

An internal agent

Configurable
parameters for the
test

1. TEST PERIOD - How often should the test be executed
2. HOST – The IP address of the WebLogic server
3. PORT – The port number of the WebLogic server
4. PSPATH – Specify the path to the ps command (The default location is
/usr/ucb). The eG user must be vested with execute permissions in order to
execute the ps command.

5. PFILESPATH - Specify the path to the pfiles command (The default is
/usr/ucb).

6. PROCESS – Takes a process name and process pattern in the format:
processName:processPattern. While the processName is a display name, the
processPattern should uniquely identify the application's process ID (PID of
the application). The processPattern can be of the form - *expr* or expr or
*expr or expr* or *expr1*expr2*... or expr1*expr2, etc. A leading '*'
signifies any number of leading characters, while a trailing '*' signifies any
number of trailing characters. For instance, the PROCESS parameter can be
configured as: iplanet:*Xms*, where iplanet is the name that will be
displayed in the eG monitor interface, and *Xms* is the process pattern that
needs to be monitored. *Xms* will monitor only those processes which
contain the string "Xms". Multiple processes can be defined as a commaseparated list.

Outputs of the test
Measurements
made by the test

One set of results for every descriptor monitored

Measurement

Measurement
Unit

138

Interpretation

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Rlimit fd current:

S e r v e r s

Number

The current limit of file
descriptors associated with
a particular application.
Each application has a limit
on the number of file
descriptors which it can
use. The default is 256.
Number
of
descriptors open:

file

Number

The
number
of
file
descriptors which are open
at present

Usage
of
descriptors:

file

A consistent increase in the value of
this measure over a period of time
could indicate that file handles are
not being released properly. If the
problem is not addressed soon, it
could seriously hamper application
performance.

Percent

The percentage usage of
the file descriptors for the
application

2.1.3.12

WebLogic Connectors Test

This test extracts connector related statistics from a managed WebLogic server. This test is not
available by default. To enable the test, go to the ENABLE / DISABLE TESTS page using the menu sequence
: Agents -> Tests -> Enable/Disable, pick WebLogic as the Component type, Performance as the Test
type, choose the test from the DISABLED TESTS list, and click on the >> button to move the test to the
ENABLED TESTS list. Finally, click the Update button.

Purpose

Generates connector-related statistics from a managed WebLogic server

Target of the test

Any managed WebLogic server

Agent deploying the
test

An internal agent

139

M o n i t o r i n g

W e b L o g i c

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

1. TESTPERIOD - How often should the test be executed
2. HOST – The IP address of the WebLogic server
3. PORT – The port number of the WebLogic server
4. USER – The admin user name of the WebLogic server being monitored.
5. PASSWORD – The password of the specified admin user
6. CONFIRM PASSWORD – Confirm the password by retyping it here.
7. ENCRYPTPASS - If the specified password needs to be encrypted, set the
ENCRYPTPASS flag to YES. Otherwise, set it to NO. By default, the YES option
will be selected.

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS
flag is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to
connect to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of
the server. This parameter can be changed to a value of
http://:. In this case, the test
connects to the WebLogic admin server to collect metrics pertaining to the
managed server (specified by the HOST and PORT). The URL setting
provides the administrator with the flexibility of determining the WebLogic
monitoring configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed
to the admin server, and it is up and running.
11. VERSION - The VERSION textbox indicates the version of the Weblogic
server to be managed. The default value is "none", in which case the test
auto-discovers the weblogic version. If the value of this parameter is not
"none", the test uses the value provided (e.g., 7.0) as the weblogic version
(i.e., it does not auto-discover the weblogic server version). This parameter
has been added to address cases when the eG agent is not able to discover
the WebLogic server version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done
using a Web archive file deployed on the WebLogic server (in which case,
HTTP/HTTPS is used by the server to connect to the server). If this flag is
set to No, the agent directly connects to the WebLogic server using the T3
protocol (no other file needs to be deployed on the WebLogic server for this
to work). Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only. Also, if the USEWARFILE parameter is set to No, make
sure that the ENCRYPTPASS parameter is set to No as well.

140

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

When monitoring a WebLogic server deployed on a Unix platform
particularly, if the USEWARFILE parameter is set to No, you have to make
sure that the eG agent install user is added to the WebLogic users group.
13. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's
java archive (Jar) file. If the USEWARFILE flag is set to No, then the
weblogic.jar file specified here is used to connect to the corresponding
WebLogic server using the T3 protocol. Note that the T3 protocol-based support is
available for WebLogic servers ver.9 and ver. 10 only.

Outputs of the test
Measurements
made by the test

One set of results for every WebLogic server being monitored

Measurement
Unit

Measurement
Connection created:

Conns/sec

Returns the total number of
connector
connections
created in this connector
pool since the pool was
instantiated
Connections destroyed:

Conns/sec

Returns the total number of
connector
connections
destroyed in this connector
pool since the pool was
instantiated
Connections matched:

Conns/Sec

Returns the total number of
times a request for a
connector connection was
satisfied via the use of an
existing created connection,
since
the
pool
was
instantiated
Connection rejects:

Conns/Sec

Returns the total number of
rejected requests for a
connector connection in this
connector pool since the pool
was instantiated
Connections recycled:

Conns/Sec

Returns the total number of
connector connections that
have been recycled in this
connector pool since the pool
was instantiated

141

Interpretation

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Current
connections:

S e r v e r s

active

Number

Returns the current total
number
of
active
connections
Active connections
water mark:

high

Number

Returns the high water mark
of active connections in this
connector pool since the pool
was instantiated
Current free connections:

Number

Returns the current total free
connections
Free
connections
water mark:

high

Number

Returns the high water mark
of free connections in this
connector pool since the pool
was instantiated
Max capacity:

Number

Returns
the
maximum
capacity configured for this
connector connection pool

2.1.4 The WebLogic Database Layer
The status of the database connectivity from the WebLogic server to one or more backend database
servers is assessed by the WebLogic Database layer. The status of the WebLogic Database layer is
determined based on the results of a WebLogicJdbc test that is shown in Figure 2.17.

Figure 2.17: Tests mapping to the WebLogic Database layer

142

M o n i t o r i n g

2.1.4.1

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

WebLogic JDBC Test

The WebLogic JDBC test collects measures related to JDBC pools created on the WebLogic server.

Purpose

Collects measures related to JDBC pools created on the WebLogic server

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

143

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST – The IP address of the WebLogic server
3. PORT – The port number of the WebLogic server
4. SNMPPORT – The port number on which the WebLogic server is exposing its
SNMP MIB (relevant to WebLogic server 5.1 only). For version 6.0 and above,
enter “none” in this text box.
5. SNMPCOMMUNITY – The SNMP community string to be used with the SNMP
query to access the WebLogic server’s MIB (relevant to WebLogic server 5.1
only). For version 6.0 and above, enter “none” in this text box.
6. SNMPVERSION – By default, the eG agent supports SNMP version 1. Accordingly,
the default selection in the SNMPVERSION list is v1. However, if a different SNMP
framework is in use in your environment, say SNMP v2 or v3, then select the
corresponding option from this list.
7. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
8. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
9. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
10. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm

144

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



DES – Data Encryption Standard



AES – Advanced Encryption Standard

145

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

23. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only . Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.
When monitoring a WebLogic server deployed on a Unix platform particularly, if
the USEWARFILE parameter is set to No, you have to make sure that the eG
agent install user is added to the WebLogic users group.
24. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's java
archive (Jar) file. If the USEWARFILE flag is set to No, then the weblogic.jar file
specified here is used to connect to the corresponding WebLogic server using
the T3 protocol. Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only.
25. TIMEOUT - Specify the duration (in seconds) within which the SNMP query
executed by this test should time out in the TIMEOUT text box. The default is 10
seconds.

Outputs of the
test
Measurements
made by the
test

One set of results for each connection pool used by a WebLogic application server.

Measurement
Pool availability:

Measurement
Unit
Percent

A value of 100 denotes that the
pool is available; a value of 0
denotes unavailability.

Percent

When this value reaches 100%,
connections to the database will
either have to wait for access or will
time out. Consider increasing the
size of the connection pool in this
case. A very high percentage of use
can also result if one or more of the
applications that use the connection
pool
are
not
releasing
the
connections after their use.

The current state of a
database connection pool –
whether it is available or not
Percent of connections
used:
Percentage of database
connection allocated to a
connection pool that are in use

Max capacity:

Number

The maximum number of
connections configured for a
JDBC connection pool
Active connections current:

Interpretation

Number

The number of connections
currently in use for a JDBC
connection pool

146

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Waiting for connections:

S e r v e r s

Number

A high value of pending connections
is indicative of a bottleneck during
database access. Reasons for this
could either be that the connection
pool capacity is insufficient, or that
the database server has slowed
down, causing requests to take
longer to execute their queries.

Number

Note the changes in the high water
mark. This can give you an idea
about the times when the JDBC
pool was most heavily used.

Number

Note the changes in the high water
mark. This indicates periods when
the database connection pool could
have been a bottleneck.

The number of requests for
connections to the database
that are currently pending

Active connections max:
The high water mark of active
connections in a pool
Waiting for connections
max:
The high water mark of
number of waiters for a
connection from the pool
Connections added to pool:

Number

The
number
of
JDBC
connections added to the pool
in
the
last
measurement
period
Leaked connections:

Number

A non-zero value indicates that the
application may not be releasing
connections after use. This can
result in inefficient management of
the database connections in the
pool.

Number

Failures could happen if the
database is unavailable, or, the
connection was terminated.

Secs

An increase in this metric could
indicate
a bottleneck
in
the
database tier.

The number of connections
tagged as a leaked connection
during the last measurement
period. A leaked connection is
a connection that was checked
out from the connection pool
but was not returned to the
pool by calling close().
Failures to reconnect:
The number of cases during
the last measurement period
when
a
connection
pool
attempted
to
refresh
a
connection to the database
and failed.
Connection delay time:
Avg. time taken to get a
connection from the database
(in seconds)
Max wait to get connection:

Secs

The high water mark of the
time a thread had to wait in
order to get a connection from
the pool

147

M o n i t o r i n g

2.1.4.2

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

WL JDBC Test

This test also measures statistics pertaining to the JDBC database connection pools in use by the
WebLogic server. This test is disabled by default and is included for backward compatibility only. This
test is disabled by default. To enable the test, go to the ENABLE / DISABLE TESTS page using the menu
sequence : Agents -> Tests -> Enable/Disable, pick WebLogic as the Component type, Performance as
the Test type, choose this test from the DISABLED TESTS list, and click on the >> button to move the test
to the ENABLED TESTS list. Finally, click the Update button.

Purpose

To measure statistics pertaining to the database connection pool usage of a
WebLogic application server

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

148

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST – The IP address of the WebLogic server
3. PORT – The port number of the WebLogic server
4. SNMPPORT – The port number on which the WebLogic server is exposing its
SNMP MIB (relevant to WebLogic server 5.1 only). For version 6.0 and above,
enter “none” in this text box.
5. SNMPCOMMUNITY – The SNMP community string to be used with the SNMP
query to access the WebLogic server’s MIB (relevant to WebLogic server 5.1
only). For version 6.0 and above, enter “none” in this text box.
6. SNMPVERSION – By default, the eG agent supports SNMP version 1. Accordingly,
the default selection in the SNMPVERSION list is v1. However, if a different SNMP
framework is in use in your environment, say SNMP v2 or v3, then select the
corresponding option from this list.
7. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
8. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
9. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
10. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:


MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm

149

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

DES – Data Encryption Standard



AES – Advanced Encryption Standard

150

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

22. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only . Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.
When monitoring a WebLogic server deployed on a Unix platform particularly, if
the USEWARFILE parameter is set to No, you have to make sure that the eG
agent install user is added to the WebLogic users group.
23. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's java
archive (Jar) file. If the USEWARFILE flag is set to No, then the weblogic.jar file
specified here is used to connect to the corresponding WebLogic server using
the T3 protocol. Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only.
24. VERSION - The VERSION textbox indicates the version of the Weblogic server to
be managed. The default value is "none", in which case the test auto-discovers
the weblogic version. If the value of this parameter is not "none", the test uses
the value provided (e.g., 7.0) as the weblogic version (i.e., it does not autodiscover the weblogic server version). This parameter has been added to
address cases when the eG agent is not able to discover the WebLogic server
version.

Outputs of the
test
Measurements
made by the
test

One set of results for each connection pool used by a WebLogic application server.

Measurement
Connection usage percent:

Measurement
Unit
Percent

Number

Percentage of database
connections allocated to a
connection pool that is in use

Pending connections:

Interpretation

Number of requests for
connections to the database
that are currently pending

151

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Max connections:

S e r v e r s

Number

The maximum number of
connections configured for a
JDBC connection pool
Current connections:

Number

The current number of
connections in use for a JDBC
connection pool
Pool availability:

Percent

A value of 100 denotes that the
pool is available; a value of 0
denotes unavailability.

Number

Failures could happen if the
database is unavailable, or, the
connection was terminated.

The
current
state
of
a
database connection pool –
whether it is available or not
Failed reconnects:
The number of cases during
the last measurement period
when
a
connection
pool
attempted
to
refresh
a
connection to the database
and failed
Connections to pool:

Number

The
number
of
JDBC
connections added to the pool
in
the
last
measurement
period
Avg connection delay:

Secs

An increase in this metric could
indicate
a bottleneck
in
the
database tier.

Number

A non-zero value indicates that the
application may not be releasing
connections after use. This can
result in inefficient management of
the database connections in the
pool.

Number

Note the changes in the high water
mark. This can provide an idea of
the times when the JDBC pool was
most heavily used.

Avg. time taken to get a
connection from the database
(in seconds)
Leaked connections:
Number of connections tagged
as a leaked connection during
the last measurement period.
A leaked connection is a
connection that was checked
out from the connection pool
but was not returned to the
pool by calling close().
Active connections high
mark:
The high water mark of active
connections in a pool

152

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Waiting connections high
mark:

S e r v e r s

Number

The high water mark of
number of waiters for a
connection from the pool

153

Note the changes in the high water
mark. This indicates periods when
the database connection pool could
have been a bottleneck.

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
The Failed reconnects, Avg connection delay and Leaked connections measures will always
report 0 for WebLogic 6.0 with Service Pack 2.0.

2.1.4.3

Jdbc Stats Test

The JdbcStats test collects measures like how many JDBC queries have been executed, how long
those queries took to execute and what those statements are. This test is key to determining whether
the database/database queries are the cause of any slowdowns with applications executing on the
WebLogic server. This test is disabled by default. To enable the test, go to the ENABLE / DISABLE TESTS
page using the menu sequence : Agents -> Tests -> Enable/Disable, pick WebLogic as the Component
type, Performance as the Test type, choose this test from the DISABLED TESTS list, and click on the >>
button to move the test to the ENABLED TESTS list. Finally, click the Update button.

Purpose

Collects measures like how many JDBC queries have been executed, how long those
queries took to execute and what those statements are

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

154

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST – The IP address of the WebLogic server
3. PORT – The port number of the WebLogic server
4. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of the
server.
This
parameter
can
be
changed
to
a
value
of
http://:. In this case, the test connects
to the WebLogic admin server to collect metrics pertaining to the managed
server (specified by the HOST and PORT). The URL setting provides the
administrator with the flexibility of determining the WebLogic monitoring
configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed to
the admin server, and it is up and running.

5. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for a WebLogic application server

Measurement
Total query rate:

Measurement
Unit
Queries/Sec

This is an indicator of the JDBC
workload.

Secs

A higher average query time
signifies a performance bottleneck
at the data abase tier.

The rate of JDBC queries that
have been executed on the
database, using the pools that
have been configured to use
the P6Spy driver
Avg query time:

Interpretation

The average time taken by the
queries to execute on the
database, using the pools that
have been configured to use
the P6Spy driver

155

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Select query rate:

S e r v e r s

Queries/Sec

Comparing the types of queries to
the database provides an idea
about the nature of workload on the
database

Secs

Unexpectedly large query times can
indicate that there is sufficient
scope to optimize database access
using better indexes.

The rate of select queries
executed on the database,
using the pools that have been
configured to use the P6Spy
driver
Avg Select query time:
The average time taken by the
select queries for executing on
the database, by using the
pools
that
have
been
configured to use the P6Spy
driver

Insert query rate:

Queries/Sec

The rate of insert queries
executed on the database,
using the pools that have been
configured to use the P6Spy
driver
Avg insert query time:

Secs

The average time taken for
executing the insert queries on
the database, using the pools
that have been configured to
use the P6Spy driver
Update query rate:

Queries/Sec

The rate of update queries
executed on the database,
using the pools that have been
configured to use the P6Spy
driver
Avg update query time:

Secs

The average time taken for
executing the update queries
on the database, using the
pools
that
have
been
configured to use the P6Spy
driver
Delete query rate:

Queries/Sec

The rate of delete queries
executed on the database,
using the pools that have been
configured to use the P6Spy
driver

156

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Avg delete query time:

S e r v e r s

Secs

The average time taken by the
delete queries to execute on
the database, using the pools
that have been configured to
use the P6Spy driver
Commit queries rate:

Queries/Sec

The rate of commit queries
executed on the database,
using the pools that have been
configured to use the P6Spy
driver
Avg commit query time:

Secs

The average time taken by the
commit queries to execute on
the database, using the pools
that have been configured to
use the P6Spy driver
Rollback queries rate:

Queries/Sec

The rate of rollback queries
executed on the database,
using the pools that have been
configured to use the P6Spy
driver
Avg rollback query time:

Typically, the
should be low.

rate

rollbacks

Secs

The average time taken by the
rollback queries to execute on
the database, using the pools
that have been configured to
use the P6Spy driver
Jdbc query error rate:

Errors/Sec

The rate of queries that have
resulted in an error

2.1.5 The WebLogic EJB Layer
Following are three different kinds of EJB components that can be hosted on a WebLogic server 6.0 or
higher:

a. A stateful session bean is an enterprise bean that acts as a server-side extension of the client
that uses it. The stateful session bean is created by a client and will work for only that client
until the client connection is dropped or the bean is explicitly removed.

b. A stateless session bean is an enterprise bean that provides a stateless service to the client
c. An entity bean represents a business object in a persistent storage mechanism such as a
database. For example, an entity bean could represent a customer, which might be stored as a
row in the customer table of a relational database

157

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Figure 2.18: Tests mapping to the WebLogic EJB layer
The Weblogic EJB layer is mapped to a wide variety of tests, each of which report key statistics
pertaining to a critical EJB operation.

2.1.5.1

WebLogic EJB Locks Test

The WebLogic EJB Lock test monitors the EJB locking activity performed by the WebLogic server. Use
the Click here hyperlink in the test configuration page to configure the EJB groups that need to be
monitored by the eG Enterprise suite. By default, the eG Enterprise system will monitor only those EJBs that are

part of a group.
Purpose

Monitors the EJB locking activity performed by the WebLogic server

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

158

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS flag
is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. AUTODISCOVERY – By default, eG Enterprise allows administrators to configure
EJB groups using the eG administrative interface, and reports metrics pertaining
to every group so created. Accordingly, by default, AUTODISCOVERY is set to
NO. If you want EJBs to be discovered and monitored automatically, then select
the YES option against AUTODISCOVERY. When this is done, the eG agent
automatically discovers all the EJBs on the WebLogic server, and reports one set
of measures for every EJB so discovered.
11. SHOWSERVERNAME - WebLogic version 8.0 and above prefixes the names of
the EJBs it hosts, with the server name specified in the SERVER text box. For
example, if the SERVER text box contains MedRecServer, then an EJB named
MedRecEAR_EntityEJB_PatientEJB on that server will be renamed by WebLogic
as MedRecServer_MedRecEAR_EntityEJB_PatientEJB. This could pose a
challenge while applying EJB groups configured (using eG) on a particular
WebLogic server to another server. This is because, when the eG Enterprise
suite lists the EJBs available for grouping, each of the displayed EJBs will be
prefixed by the corresponding SERVER name. When such EJBs are grouped and
the group is then applied to another WebLogic server, the eG Enterprise system
will not be able to extract metrics for the EJB grouping applied to the new server
due to the server name mismatch. Therefore, by default, the eG Enterprise
system sets the SHOWSERVERNAME flag to No. This ensures that the server
name specified in the SERVER text box does not prefix the EJB listing during EJB
group configuration. To enable the prefix, select the Yes option against
SHOWSERVERNAME.
Note:
If you modify the SHOWSERVERNAME setting after configuring the EJB groups,
then wait for the test to run once so that the eG agent rediscovers the EJBs on
that server. Then, delete the existing EJB groups, and repeat the group
configuration.

159

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

12. URL – The URL to be accessed to collect metrics pertaining to the WebLogic
server. By default, this test connects to a managed WebLogic server and
attempts to obtain the metrics of interest by accessing the local Mbeans of the
server.
This
parameter
can
be
changed
to
a
value
of
http://:. In this case, the test connects
to the WebLogic admin server to collect metrics pertaining to the managed
server (specified by the HOST and PORT). The URL setting provides the
administrator with the flexibility of determining the WebLogic monitoring
configuration to use.
Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed to
the admin server, and it is up and running.
13. VERSION - The VERSION textbox indicates the version of the Weblogic server to
be managed. The default value is "none", in which case the test auto-discovers
the weblogic version. If the value of this parameter is not "none", the test uses
the value provided (e.g., 7.0) as the weblogic version (i.e., it does not autodiscover the weblogic server version). This parameter has been added to
address cases when the eG agent is not able to discover the WebLogic server
version.
14. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only . Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.
When monitoring a WebLogic server deployed on a Unix platform particularly, if
the USEWARFILE parameter is set to No, you have to make sure that the eG
agent install user is added to the WebLogic users group.
15. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's java
archive (Jar) file. If the USEWARFILE flag is set to No, then the weblogic.jar file
specified here is used to connect to the corresponding WebLogic server using
the T3 protocol. Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only.
16. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

160

M o n i t o r i n g

Outputs of the
test
Measurements
made by the
test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

One set of results for every EJB group configured using the eG administrative
interface

Measurement
Locked beans count:

Measurement
Unit

Interpretation

Number

The sum total of the beans
from within an EJB group that
are currently locked
Attempts to lock rate:
The sum total of the rate at
which attempts were made to
obtain a lock on every bean
within an EJB group
Timeout rate:
The sum total of the rate at
which threads have timed out
waiting for a lock on every
bean within an EJB group
Threads waiting rate:

Attempts/S
ec

Timeouts/S
ec

Threads/Sec

The sum total of the rate at
which threads have been
waiting for a lock on every
bean in an EJB group

The detailed diagnosis of this
measure, if enabled, provides
locking information pertaining to
the
individual
beans
in
the
monitored EJB group. The details
displayed include: The Bean name,
the number of locked beans, the
number of attempts made to lock,
the timeout rate, and the threads
waiting rate of the bean. Note that

the detailed diagnosis information will not
be available if the AUTODISCOVERY
parameter is set to ‘Yes’.

2.1.5.2

WebLogic EJB Cache Test

To improve the performance and the scalability of the EJB container, WebLogic server caches EJBs.
The WebLogicEJBCache test collects measures related to EJB caching activity by the WebLogic server.
Use the Click here hyperlink in the test configuration page to configure the EJB groups that need to be
monitored by the eG Enterprise suite. By default, the eG Enterprise system will monitor only those EJBs that are

part of a group.
Purpose

Collects measures related to EJB caching activity by the WebLogic server

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

161

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS flag
is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. AUTODISCOVERY – By default, eG Enterprise allows administrators to configure
EJB groups using the eG administrative interface, and reports metrics pertaining
to every group so created. Accordingly, by default, AUTODISCOVERY is set to
NO. If you want EJBs to be discovered and monitored automatically, then select
the YES option against AUTODISCOVERY. When this is done, the eG agent
automatically discovers all the EJBs on the WebLogic server, and reports one set
of measures for every EJB so discovered.
11. SHOWSERVERNAME - WebLogic version 8.0 and above prefixes the names of
the EJBs it hosts, with the server name specified in the SERVER text box. For
example, if the SERVER text box contains MedRecServer, then an EJB named
MedRecEAR_EntityEJB_PatientEJB on that server will be renamed by WebLogic
as MedRecServer_MedRecEAR_EntityEJB_PatientEJB. This could pose a
challenge while applying EJB groups configured (using eG) on a particular
WebLogic server to another server. This is because, when the eG Enterprise
suite lists the EJBs available for grouping, each of the displayed EJBs will be
prefixed by the corresponding SERVER name. When such EJBs are grouped and
the group is then applied to another WebLogic server, the eG Enterprise system
will not be able to extract metrics for the EJB grouping applied to the new server
due to the server name mismatch. Therefore, by default, the eG Enterprise
system sets the SHOWSERVERNAME flag to No. This ensures that the server
name specified in the SERVER text box does not prefix the EJB listing during EJB
group configuration. To enable the prefix, select the Yes option against
SHOWSERVERNAME.
Note:
If you modify the SHOWSERVERNAME setting after configuring the EJB groups,
then wait for the test to run once so that the eG agent rediscovers the EJBs on
that server. Then, delete the existing EJB groups, and repeat the group
configuration.

162

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

 The eG manager license should allow the detailed diagnosis capability
 Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

163

M o n i t o r i n g

Outputs of the
test
Measurements
made by the
test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

One set of results for every EJB group configured using the eG administrative
interface

Measurement
Activation rate:

Measurement
Unit

Interpretation

Beans/Sec

The sum total of the rate at
which every bean from a
particular EJB group have been
activated
Passivation rate:

Beans/Sec

The sum total of the rate at
which the every bean from a
specific EJB group have been
passivated
Cache hit rate:

Hits/Sec

The sum total of the rate at
which attempts to access
every bean within an EJB
group,
from
the
cache
succeeded
Cache miss rate:

Misses/Sec

The sum total of the rate at
which attempts to access
every bean within an EJB
group, from the cache failed
Cache hit ratio:

Percent

The average of the percentage
of time every bean in an EJB
group was successfully
accessed from the cache
Beans in cache:

Number

The number of beans in the
cache

The detailed diagnosis of the Cache hit ratio measure, provides the details pertaining to the EJB
caching activity of the individual beans in the EJB group being monitored (see Figure 2.19). This
information enables administrators to assess the effectiveness of the caching activity performed by the
WebLogic server. Note that the detailed diagnosis information will not be available if the AUTODISCOVERY

parameter is set to ‘Yes’.

164

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Figure 2.19: The detailed diagnosis of the Cache hit ratio measure

2.1.5.3

WebLogic EJB Pools Test

This test collects measures related to the bean pooling activity performed by the WebLogic server. Use
the Click here hyperlink in the test configuration page to configure the EJB groups that need to be
monitored by the eG Enterprise suite. By default, the eG Enterprise system monitors only those EJBs that are

part of a group.
Purpose

Collects measures related to the bean pooling activity performed by the WebLogic
server

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

165

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS flag
is also set to No.

8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.

9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")

10. AUTODISCOVERY – By default, eG Enterprise allows administrators to configure
EJB groups using the eG administrative interface, and reports metrics pertaining
to every group so created. Accordingly, by default, AUTODISCOVERY is set to
NO. If you want EJBs to be discovered and monitored automatically, then select
the YES option against AUTODISCOVERY. When this is done, the eG agent
automatically discovers all the EJBs on the WebLogic server, and reports one set
of measures for every EJB so discovered.

11. SHOWSERVERNAME - WebLogic version 8.0 and above prefixes the names of
the EJBs it hosts, with the server name specified in the SERVER text box. For
example, if the SERVER text box contains MedRecServer, then an EJB named
MedRecEAR_EntityEJB_PatientEJB on that server will be renamed by WebLogic
as MedRecServer_MedRecEAR_EntityEJB_PatientEJB. This could pose a
challenge while applying EJB groups configured (using eG) on a particular
WebLogic server to another server. This is because, when the eG Enterprise
suite lists the EJBs available for grouping, each of the displayed EJBs will be
prefixed by the corresponding SERVER name. When such EJBs are grouped and
the group is then applied to another WebLogic server, the eG Enterprise system
will not be able to extract metrics for the EJB grouping applied to the new server
due to the server name mismatch. Therefore, by default, the eG Enterprise
system sets the SHOWSERVERNAME flag to No. This ensures that the server
name specified in the SERVER text box does not prefix the EJB listing during EJB
group configuration. To enable the prefix, select the Yes option against
SHOWSERVERNAME.

Note:
If you modify the SHOWSERVERNAME setting after configuring the EJB groups,
then wait for the test to run once so that the eG agent rediscovers the EJBs on
that server. Then, delete the existing EJB groups, and repeat the group
configuration.

166

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

13. VERSION - The VERSION textbox indicates the version of the Weblogic server to
be managed. The default value is "none", in which case the test auto-discovers
the weblogic version. If the value of this parameter is not "none", the test uses
the value provided (e.g., 7.0) as the weblogic version (i.e., it does not autodiscover the weblogic server version). This parameter has been added to
address cases when the eG agent is not able to discover the WebLogic server
version.

14. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only. Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.
When monitoring a WebLogic server deployed on a Unix platform particularly, if
the USEWARFILE parameter is set to No, you have to make sure that the eG
agent install user is added to the WebLogic users group.

15. WEBLOGICJARLOCATION - Specify the location of the WebLogic server's java
archive (Jar) file. If the USEWARFILE flag is set to No, then the weblogic.jar file
specified here is used to connect to the corresponding WebLogic server using
the T3 protocol. Note that the T3 protocol-based support is available for WebLogic servers
ver.9 and ver. 10 only.

16. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:


The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

167

M o n i t o r i n g

Outputs of the
test
Measurements
made by the
test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

One set of results for every EJB group configured using the eG administrative
interface

Measurement
Beans in use:

Measurement
Unit

Interpretation

Number

The sum total of instances of
every bean in an EJB group
that are currently being used
from the free pool
Idle beans:

Number

The sum total of the instances
of every bean within an EJB
group
that
are
currently
available in the free pool
Waiting threads:

Number

The sum total of threads
currently waiting for every
available bean instance in an
EJB group
Thread timeouts:

Threads/Sec

The sum total of the number of
threads that have timed out
waiting
for
an
available
instance of every bean in an
EJB group
Access attempts:

Number

This measure will be available on
WebLogic servers 8.0 and above
only.

Number

This measure will be available on
WebLogic servers 8.0 and above
only.

An access attempt is an
attempt made to get an
instance of a bean from the
free
pool.
The
Access_attempts
measure
reports the sum total of all
such attempts made for every
bean in an EJB group.
Missed attempts:
A missed attempt is a failed
attempt made to get an
instance of a bean from the
free
pool.
The
Missed_attempts
measure
reports the sum total of all
such failed attempts made for
every bean in an EJB group.

168

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Destroyed beans:

S e r v e r s

Number

If an instance of a bean (in an
EJB group) from a pool was
destroyed due to a nonapplication Exception being
thrown from it, then the bean
is deemed destroyed. The
Destroyed_beans
measure
reports the sum total of all the
beans in an EJB group that
threw
a
non-application
Exception.

This measure will be available on
WebLogic servers 8.0 and above
only.

The detailed diagnosis of the Waiting threads (see Figure 2.20) and the Thread timeouts measures
provides the details related to the usage of the individual beans present in the EJB group being
monitored. This information enables administrators to evaluate the effectiveness of the bean pooling
activity of the WebLogic server. Note that the detailed diagnosis information will not be available if the
AUTODISCOVERY parameter is set to ‘Yes’.

Figure 2.20: The detailed diagnosis of the Threads timeout measure

2.1.5.4

WebLogic EJB Pool Test

The WebLogic EJB PoolTest collects measures related to the bean pooling activity performed by the
WebLogic server. This test will be disabled by default. You can enable this test by clicking on the check
box corresponding to the test in the AGENTS – TESTS CONFIGURATION page, and then clicking on the Update
button. Use the Click here hyperlink in the test configuration page to configure the EJB groups that
need to be monitored by the eG Enterprise suite. By default, the eG Enterprise system monitors only those

EJBs that are part of a group.
Purpose

Collects measures related to the bean pooling activity performed by the WebLogic
server

Target of the

A WebLogic application server
169

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

test
Agent
deploying the
test

An internal agent

170

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS flag
is also set to No.
8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.
9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")
10. AUTODISCOVERY – By default, eG Enterprise allows administrators to configure
EJB groups using the eG administrative interface, and reports metrics pertaining
to every group so created. Accordingly, by default, AUTODISCOVERY is set to
NO. If you want EJBs to be discovered and monitored automatically, then select
the YES option against AUTODISCOVERY. When this is done, the eG agent
automatically discovers all the EJBs on the WebLogic server, and reports one set
of measures for every EJB so discovered.
11. SHOWSERVERNAME - WebLogic version 8.0 and above prefixes the names of
the EJBs it hosts, with the server name specified in the SERVER text box. For
example, if the SERVER text box contains MedRecServer, then an EJB named
MedRecEAR_EntityEJB_PatientEJB on that server will be renamed by WebLogic
as MedRecServer_MedRecEAR_EntityEJB_PatientEJB. This could pose a
challenge while applying EJB groups configured (using eG) on a particular
WebLogic server to another server. This is because, when the eG Enterprise
suite lists the EJBs available for grouping, each of the displayed EJBs will be
prefixed by the corresponding SERVER name. When such EJBs are grouped and
the group is then applied to another WebLogic server, the eG Enterprise system
will not be able to extract metrics for the EJB grouping applied to the new server
due to the server name mismatch. Therefore, by default, the eG Enterprise
system sets the SHOWSERVERNAME flag to No. This ensures that the server
name specified in the SERVER text box does not prefix the EJB listing during EJB
group configuration. To enable the prefix, select the Yes option against
SHOWSERVERNAME.

171

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

172

M o n i t o r i n g

Outputs of the
test
Measurements
made by the
test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

One set of results for every EJB group configured using the eG administrative
interface

Measurement
Beans in use:

Measurement
Unit

Interpretation

Number

The sum total of instances of
every bean in an EJB group
that are currently being used
from the free pool
Idle beans:

Number

The sum total of the instances
of every bean within an EJB
group
that
are
currently
available in the free pool
Waiting threads:

Number

The sum total of threads
currently waiting for every
available bean instance in an
EJB group
Threads timeout rate:

Threads/Sec

The sum total of the rate at
which threads have timed out
waiting
for
an
available
instance of every bean in an
EJB group

2.1.5.5

WebLogic EJB Transactions Test

This test collects measures related to the EJB transaction activity performed by the WebLogic server.
Use the Click here hyperlink in the test configuration page to configure the EJB groups that need to be
monitored by the eG Enterprise suite. By default, the eG Enterprise system monitors only those EJBs that are

part of a group.
Purpose

Collects measures related to the EJB transaction activity performed by the WebLogic
server

Target of the
test

A WebLogic application server

Agent
deploying the
test

An internal agent

173

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
If the USEWARFILE flag is set to No, then make sure that the ENCRYPTPASS flag
is also set to No.

8. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to connect
to the WebLogic server.

9. SERVER - The name of the specific server instance to be monitored for a
WebLogic server (the default value is "localhome")

174

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

14. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only . Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.
When monitoring a WebLogic server deployed on a Unix platform particularly, if
the USEWARFILE parameter is set to No, you have to make sure that the eG
agent install user is added to the WebLogic users group.

The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

175

M o n i t o r i n g

Outputs of the
test
Measurements
made by the
test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

One set of results for every EJB group configured using the eG administrative
interface

Measurement
Transaction commits:

Measurement
Unit
Trans/Sec

Comparing this value across all the
deployed groups can give an idea of
the relative importance of the
beans within the groups, in
supporting user accesses. A sudden
change in user access patterns can
be indicative of a change in the
user workload.

Trans/Sec

A high rollback rate indicates a
problem with specific beans within a
group. Possible reasons for this
could be problems with the design
and implementation of the specific
bean or problems with any of the
dependent servers of the bean
(e.g., database server).

Trans/Sec

A significantly high value may
denote a load on the specific bean.
This may indicate that specific
transactions are taking too long to
process requests.

Commit rate is the rate at
which
transactions
are
committed for a particular
bean. Tx_commit_rate reveals
the sum total of the commit
rates of the individual beans in
an EJB group.
Transaction rollbacks:
Rollback rate is the rate at
which the transactions are
rolled back for a particular
bean. Tx_rollback_rate reveals
the sum total of the rollback
rates of the individual beans in
an EJB group.
Transaction timeouts:

Interpretation

The timeout rate is the rate at
which the transactions are
timed out by the bean.
Tx_timeout_rate reveals the
sum total of the timeout rates
of the individual beans in an
EJB group.

The detailed diagnosis of the
Transaction
rollbacks
and
Transaction timeouts measures, if
enabled, provides the commit rate,
rollback rate, and timeout rate of
the transactions conducted by each
of the beans within the EJB group
being monitored. Note that the detailed

diagnosis information will not be
available if the AUTODISCOVERY
parameter is set to ‘Yes’.

2.1.5.6

WebLogic Ejbs Test

This test monitors the state of EJB component groups hosted on a WebLogic server 6.0 or higher using
JMX. By default, this test appears disabled in the eG administrative interface (the CONFIGURE TESTS
page) and is included for backward compatibility with earlier eG versions only. To enable the test, go
to the ENABLE / DISABLE TESTS page using the menu sequence : Agents -> Tests -> Enable/Disable, pick
WebLogic as the Component type, Performance as the Test type, choose this test from the DISABLED TESTS
list, and click on the >> button to move the test to the ENABLED TESTS list. Finally, click the Update
button.
Use the Click here hyperlink in the test configuration page to configure the EJB groups that need to be
monitored by the eG Enterprise suite. Note that the eG Enterprise system monitors only those EJBs that are part

of a group.
176

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Purpose

To measure statistics pertaining to EJB groups configured on a WebLogic application
server 6.0 or higher

Target of the
test

An EJB component hosted on the WebLogic application server version 6.0 or higher

Agent
deploying the
test

An internal agent

177

M o n i t o r i n g

Configurable
parameters for
the test

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Note:
If the admin server is to be used for collecting measures for all the managed
WebLogic servers, then it is mandatory that the egurkha war file is deployed to
the admin server, and it is up and running.
11. VERSION - The VERSION textbox indicates the version of the Weblogic server to
be managed. The default value is "none", in which case the test auto-discovers
the weblogic version. If the value of this parameter is not "none", the test uses
the value provided (e.g., 7.0) as the weblogic version (i.e., it does not autodiscover the weblogic server version). This parameter has been added to
address cases when the eG agent is not able to discover the WebLogic server
version.
12. USEWARFILE - This flag indicates whether/not monitoring is to be done using a
Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS
is used by the server to connect to the server). If this flag is set to No, the agent
directly connects to the WebLogic server using the T3 protocol (no other file
needs to be deployed on the WebLogic server for this to work). Note that the T3
protocol-based support is available for WebLogic servers ver.9 and ver. 10 only . Also, if the
USEWARFILE parameter is set to No, make sure that the ENCRYPTPASS
parameter is set to No as well.

178

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the
test

One set of results for every EJB group configured

Measurement
Transaction
rate:

commit

Measurement
Unit
Trans/Sec

Comparing this value across all the
deployed beans can give an idea of the
relative importance of the beans in
supporting user accesses. A sudden
change in user access patterns can be
indicative of a change in the user
workload.

Trans/Sec

A high rollback rate indicates a problem
with specific beans. Possible reasons for
this could be problems with the design
and implementation of the specific bean
or problems with any of the dependent
servers of the bean (e.g., database
server).

Number

A significantly high value may denote a
load on the specific bean. This may
indicate that specific transactions are
taking too long to process requests.

Conns/Sec

A high value signifies that it is taking
more time for the clients to access an
instance of the bean from the pool.

Indicates the rate at
which transactions are
committed for a
particular bean.
Transaction
rate:

rollback

Indicates the rate at
which the transactions
are rolled back for a
particular bean.
Transactions inflight:
Number of transactions
currently in progress
through a particular
bean.
Num waiting rate:

Interpretation

This measure
corresponds to only
stateless session bean.
This indicates the rate
at which connections
are established by the
client with the instances
of the bean.

179

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

Timeout rate:

S e r v e r s

Conns/Sec

A high value indicates a problem with a
specific bean. Again, the problem can
be specific to the bean implementation
or with any of the dependent servers of
the bean.

Percent

A high percentage indicates a memory
bottleneck. The timeout of the session
beans could be one of the possible
reasons.

This measure also
corresponds to the
stateless session beans.
The measure indicates
the rate at which
instances are timed out
by the bean.
Idle bean percent:
The percentage of
beans those are idle in
the cache.

2.2 Monitoring the WebLogic Server Ver. 6/7/8
The special WebLogic (6/7/8) monitoring model (see Figure 2.1) that eG Enterprise offers uses JMX
(Java Management extension), the new standard for managing java components, for monitoring
version 6, 7, and 8 of the WebLogic server. JMX allows users to instrument their applications and
control or monitor them using a management console.

Figure 2.21: Layer model of the WebLogic Application server

The sections that will follow discuss the top 4 layers of Figure 2.1, and the metrics they report. The
remaining layers have been extensively dealt with in the Monitoring Unix and Windows Servers
document.

2.2.1 The JVM Layer
A Java virtual machine (JVM), an implementation of the Java Virtual Machine Specification, interprets
compiled java binary code for a computer's processor (or "hardware platform") so that it can perform
a Java program's instructions. The Java Virtual Machine Specification defines an abstract -- rather
than a real -- machine or processor. The Specification specifies an instruction set, a set of registers, a
stack, a garbage heap, and a method area.
180

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

The tests associated with the JVM layer of WebLogic enables administrators to perform the following
functions:



Assess the effectiveness of the garbage collection activity performed on the JVM heap



Monitor WebLogic thread usage



Evaluate the performance of the BEA JRockit JVM

Figure 2.22: The tests associated with the JVM layer
Note that the WebLogic Work Manager test is not mapped to this layer, indicating that this test is not
available for WebLogic versions 6, 7, and 8.
All the tests listed in Figure 2.2 above have been discussed in Section 2.1.1 of this document.
Therefore, let us proceed to the next layer.

2.2.2 The WebLogic Service Layer
The WebLogic Service layer tracks the health of the WebLogic service. The status of the WebLogic Service
layer is determined by the results of the tests shown in Figure 2.15.

181

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

Figure 2.23: Tests mapped to the WebLogic Service layer
Note that the WebLogic Queues and WebLogic Topics tests are not mapped to this layer, indicating that
these tests are not available for WebLogic versions 6, 7, and 8. All other tests depicted by Figure 2.11
have already been discussed in Section 2.1.2.6.7 of this document.

2.2.3 The WebLogic Database Layer
The status of the database connectivity from the WebLogic server to one or more backend database
servers is assessed by the WebLogic Database layer. The status of the WebLogic Database layer is
determined based on the results of a WebLogicJdbc test that is shown in Figure 2.17.

Figure 2.24: Tests mapping to the WebLogic Database layer

182

M o n i t o r i n g

W e b L o g i c

A p p l i c a t i o n

S e r v e r s

The WebLogicJDBC test mapped to this layer has already been discussed in Section 2.1.4.1 of this
document. Therefore, let us move on to the next layer.

2.2.4 The WebLogic EJB Layer
Following are three different kinds of EJB components that can be hosted on a WebLogic server 6.0 or
higher:
1. A stateful session bean is an enterprise bean that acts as a server-side extension of the client
that uses it. The stateful session bean is created by a client and will work for only that client
until the client connection is dropped or the bean is explicitly removed.
2. A stateless session bean is an enterprise bean that provides a stateless service to the client
3. An entity bean represents a business object in a persistent storage mechanism such as a
database. For example, an entity bean could represent a customer, which might be stored as a
row in the customer table of a relational database

Figure 2.25: Tests mapping to the WebLogic EJB layer
These tests, once again, have already been discussed in Section 2.1.5 of this document.

183

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Chapter

Monitoring WebSphere
Application Servers

IBM WebSphere Application Server, a software application server, is the flagship product within
IBM's WebSphere brand. WAS is built using open standards such as J2EE, XML, and Web Services. It
works with a number of web servers including Apache HTTP Server, Netscape Enterprise Server,
Microsoft Internet Information Services (IIS), IBM HTTP Server for i5/OS, IBM HTTP Server for z/OS,
and IBM HTTP Server for AIX/Linux/Microsoft Windows/Solaris. It delivers the secure, scalable,
resilient application infrastructure you need for a Service Oriented Architecture (SOA).
Like any other application server, performance setbacks suffered by the WebSphere application server
too can affect the availability of critical services it supports. To avoid such an eventuality, you need to
continuously monitor the performance of the WebSphere application server.
The eG Enterprise suite facilitates 24x7 monitoring of the WebSphere application server and proactive
alerting of probable error conditions detected on the server. Since different versions of the WebSphere
application server vary in both capabilities and architecture, eG Enterprise employs different
mechanisms to monitor the various versions. This is why, eG Enterprise provides two separate
monitoring models for WebSphere Application server – one for version 4.0 (or 5.1) of the server, and
another for version 6.0 and above. While it uses the component-type WebSphere Application – 4/5.x
to monitor the former, the component-type WebSphere Application is used for monitoring the latter.
This chapter discusses both these models in great detail.

3.1 Monitoring the WebSphere Application Server Version
4/5.x
To obtain statistics specific to a WebSphere Application Server 4/5.x, an eG agent relies on the
Performance Monitoring Interface (PMI) API supported by the WebSphere server. Through eG
Enterprise's administrative interface, the webserver port number through which the WebSphere
servers’ applications can be accessed should be specified.
The layer model that the eG Enterprise suite uses for monitoring this WebSphere server is shown in
Figure 3.1.

184

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Figure 3.1: Layer model for a WebSphere application server – 4/5.x
The details pertaining to the Operating System, Network, Tcp, and Application Processes layer have been
discussed in the Monitoring Unix and Windows Servers document. Above the Application Processes layer
is the WebSphere Service layer.

Note:
The WebSphere application server uses a specific Java-based application process to execute the
class com.ibm.ejs.sm.server.AdminServer. The Processes test parameters for WebSphere
application servers should be configured to monitor this process.

3.1.1 The WebSphere Service Layer
This layer tracks the health of the WebSphere service. The status of the WebSphere Service layer is
determined by the results of the tests depicted by Figure 3.2.

Figure 3.2: Tests mapping to the WebSphere Service layer

3.1.1.1

WebSphere Jvm Test

This test monitors the usage of the WebSphere JVM heap.

185

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Purpose

To monitor the usage of the WebSphere JVM heap

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

186

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST – The IP address of the WebSphere application server
3. PORT – The port number of the WebSphere application server
4. WEBSERVERPORT – The port number through which the WebSphere
applications can be accessed (For IBMHTTPServer this information can be
found in the httpd.conf file located in $/conf directory.)

5. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to
connect to the WebSphere server.

6. SERVERHOSTNAME - Specify the node name of the server instance being
monitored. To know the node name, do the following



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



A list of application server instances and their corresponding node names
will then appear in the right pane of the console. From this list, you can
figure out the node name that corresponds to the application server
instance being monitored, and specify that name against the
SERVERHOSTNAME parameter.

7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many instances of
the server running on the same host

In the case of situation (a), in the NDMANAGER text box, provide the host
name of the NODE MANAGER that manages the application servers in the cluster.
To know the name of the NODE MANAGER, do the following:



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.

187

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many instances of
the server running on the same host

In case of situation (a), the CONNECTORPORT parameter will take the port
number using which the node manager communicates with the WebSphere
servers in the cluster. The connector port can be a SOAP port or an RMI port.
To know the port number, do the following:



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



Two entries that read as follows will be present in the wsadmin.properties
file:
com.ibm.ws.scripting.port=
#com.ibm.ws.scripting.port=
Both the entries will have port numbers against them. However, the
uncommented entry (the entry without the #) is the one that denotes an
active port. Therefore, specify the corresponding port number as the
CONNECTORPORT.

In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b), as

If both (a) and (b) do not apply, specify none against CONNECTORPORT.

188

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

10. PASSWORD – If security has been enabled for the WebSphere server being
monitored, then provide the PASSWORD that corresponds to the specified
USER name. If the WebSphere server does not require any authentication,
then leave the PASSWORD text box with its default setting.

12. ENCRYPTPASS – By default, this flag is set to YES, indicating that the
PASSWORD of the WebSphere server is encrypted by default. To disable
password encryption, select the NO option.

13. SERVERNAME – Specify the name of the WebSphere server instance to be
monitored. To know the instances of a WebSphere server currently available,
first, connect to the WebSphere Administrative console using the URL: http://\admin. Then,
login to the administrative console and expand the Servers node in the left
pane of the console. Next, click on the Application Servers sub-node under the
Servers node. A list of server instance Names and their corresponding Node
values will then be displayed in the right pane. One of the displayed server
instances can be specified as the value of the SERVERNAME parameter.

14. TIMEOUT - In the TIMEOUT text box, specify the maximum duration (in
seconds) for which the test will wait for a response from the application
server. The default TIMEOUT period is 60 seconds.

Outputs of the
test
Measurements
made by the test

One set of results for each WebSphere application server.

Measurement
JVM total memory:

Measurement
Unit

Interpretation

Indicates the total heap
size of the JVM.
JVM used memory:

A high value of this measure
indicates a heavy workload on the
WebSphere application server. In
such a case, you might want to
consider increasing the JVM heap
size.

A very low value of this measure is
indicative of excessive memory
utilization in the JVM.

Indicates the amount of
memory that has been
utilized by the JVM

JVM free memory:
Indicates the amount of
memory currently available
in the JVM.

3.1.1.2

WebSphere Test

Since the WebSphere application server uses Java extensively, the performance of the Java Virtual
Memory (JVM) can impact the WebSphere server’s performance. This test measures the status of the
JVM and the server’s availability.
189

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Purpose

To measure the JVM statistics and availability of a WebSphere application server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Configurable
parameters for
the test

5. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to
connect to the WebSphere server.

6. SERVERHOSTNAME - Specify the node name of the server instance being
monitored. To know the node name, do the following



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many instances of
the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.

190

M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many instances of
the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).

If both (a) and (b) do not apply, specify none against CONNECTORPORT.

191

M o n i t o r i n g

Outputs of the
test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

12. ENCRYPTPASS - If the specified password needs to be encrypted, set the
ENCRYPTPASS flag to YES. Otherwise, set it to NO. By default, the YES option
will be selected.

14. TIMEOUT - In the TIMEOUT text box, specify the maximum duration (in
seconds) for which the test will wait for a response from the application
server. The default TIMEOUT period is 60 seconds.

Measurements
made by the test

Measurement
Heap usage:

Measurement
Unit
Percent

A high percentage of the heap usage
indicates either the applications
running on this server might be
utilizing/leaking too much memory or
the server has reached the maximum
memory capacity.

Percent

A value of 100 for this measure
indicates that the server is available.
Any other value indicates that the
server is not running.

Indicates the total JVM
heap used.

Availability:
Indicates the availability of
the server.

3.1.1.3

Interpretation

WebSphere Thread Pools Test

To optimize performance and at the same time to support concurrent accesses from users, the
application server uses thread pools. It is critical to monitor a WebSphere server’s thread pools on an
ongoing basis. This test does just that.

Purpose

To measure the statistics pertaining to the thread pools that exist in the
WebSphere application server

Target of the test

A WebSphere application server
192

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Agent deploying
the test

An internal agent

Configurable
parameters for
the test

5. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to
connect to the WebSphere server.

6. SERVERHOSTNAME - Specify the node name of the server instance being
monitored. To know the node name, do the following



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many instances of
the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

193

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many instances of
the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).
If both (a) and (b) do not apply, specify none against CONNECTORPORT.

194

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

12. ENCRYPTPASS – By default, this flag is set to YES, indicating that the
PASSWORD of the WebSphere server is encrypted by default. To disable
password encryption, select the NO option.
14. SERVERNAME – Specify the name of the WebSphere server instance to be
monitored. To know the instances of a WebSphere server currently available,
first, connect to the WebSphere Administrative console using the URL: http://\admin. Then,
login to the administrative console and expand the Servers node in the left
pane of the console. Next, click on the Application Servers sub-node under the
Servers node. A list of server instance Names and their corresponding Node
values will then be displayed in the right pane. One of the displayed server
instances can be specified as the value of the SERVERNAME parameter.
15. TIMEOUT - In the TIMEOUT text box, specify the maximum duration (in
seconds) for which the test will wait for a response from the application
server. The default TIMEOUT period is 60 seconds.

http://Ttp://IPOut
puts of the test
Measurements
made by the test

One set of results for each thread pool that exists on a WebSphere application
server.

Measurement
Threads created:

Measurement
Unit
Threads/Sec

A sudden increase in the value of this
measure directly relates to an
increase in the activity happening in
this application.

Threads/Sec

A decrease in the value of this
measure indicates that the threads
are being active for a long period of
time, which might indicate anomalies
within the application.

This measure indicates the
rate at which the threads
are being created in the
pool.
Threads destroyed:

Interpretation

This measure indicates the
rate at which the threads
are being destroyed in the
pool.

195

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Active threads:

S e r v e r s

Number

Indicates the average
number of active threads
in the pool.

A high value for this measure is
indicative of a high load on this
application and combined with the
creation and destroy rates might give
insights of the application pattern.
This measure is also useful for
determining
usage
trends.
For
example, it can show the time of day
and the day of the week in which you
usually reach peak thread count. In
addition, the creation of too many
threads can result in out of memory
errors or thrashing. By watching this
metric, you can reduce excessive
memory consumption before it’s too
late.

Pool size:

Number

If the pool size is high and the
number of active threads is low, it
signifies that the threads are not
being destroyed immediately after
use.

Percent

A high value for this measure
indicates that the number of threads
in the pool needs to be increased for
effective operation of this application.
Alternatively, you may also consider
changing the maximum number of
threads that a pool can contain
However, exercise caution when
altering the maximum thread count,
as a very high thread count can
cause the app to slowdown from
excessive memory usage. Likewise,
if the maximum thread count is set
too low, it will cause requests to
block or timeout.

Indicates the average
number of threads in the
pool.
Percent maxed:
This indicates the average
percent of time the
number of threads in the
pool reached or exceeded
the configured maximum
number.

You can use this measure to see how
often you are reaching the maximum
thread count in a pool. This can be
used to tune other properties – such
as the amount of time before an idle
thread
is
destroyed
and
the
frequency of when new threads are
created.

3.1.2 The WebSphere Database Layer
This layer tracks the statistics of the database access (connection pools) of the applications hosted on
a WebSphere application server with the help of the WebSphereJdbc test (see Figure 3.3).

196

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Figure 3.3: Tests mapping to the WebSphere Database layer

3.1.2.1

WebSphere JDBC Test

Rather than opening and closing connections for individual database accesses, the WebSphere
application server creates pools of database connections that are reused. To understand the
performance of a WebSphere application server, it is critical to monitor the usage of the connection
pools by the server.

Purpose

To measure the statistics pertaining to the database connection pools that exist in
the WebSphere application server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

197

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

number

through

which

the

WebSphere

5. SSL – Indicate whether the SSL (Secured Socket Layer) is to be used to
connect to the WebSphere server.
6. SERVERHOSTNAME - Specify the node name of the server instance being
monitored. To know the node name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many instances of
the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.

198

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).
If both (a) and (b) do not apply, specify none against CONNECTORPORT.

199

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the test

One set of results for each database connection pool that exists on the WebSphere
application server being monitored.

Measurement
Database connection
rate:

Measurement
Unit
Conns/Sec

A sudden increase in the value of this
measure directly relates to an
increase in the database activity
happening in this application.

Conns/Sec

A decrease in the value of this
measure points to an unusual
performance of the application. The
application might not be releasing
the connections.

Conns/Sec

A low value of this measure might be
due to some applications that are not
releasing the connections to the pool.

Conns/Sec

A high value for this measure
indicates more activity happening on
the server. An unusually high value
for this measure might result in the
pool running out of connections, if
the Return_rate is not concurrent.

Indicates the rate at which
the connections are
created in the pool.
Connection destroy
rate:
Indicates the rate at which
the connections are
released from the pool.
Connection return rate:
This measure indicates the
rate at which the
connections are being
returned to the pool.
Allocate rate:

Interpretation

Indicates the rate at which
the connections are
allocated from the pool.

200

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Pool size:

S e r v e r s

Number

A growing pool size may be due to
some
of
the
applications
not
releasing connections to the pool.

Number

A high value indicates a bottleneck
on the application server. This may
be
caused
due to unreleased
connections.

Secs

An increase in this measure reflects a
server bottleneck.

Faults/Sec

A high value is indicative
bottleneck on the server.

Percent

This measure should not reach the
maximum of 100% for optimal
performance
of
the
application
server. To reduce this value, try
increasing the pool size.

Percent

A high value indicates that the pool
size needs to be increased for
effective operation of this application.

Stmts/Sec

A high value indicates a bottleneck in
the application. It is a sign of
inefficient
performance
of
the
application.

Indicates the number of
connections in the pool. It
indicates the active pool
size.
Concurrent waiters:
Indicates the average
number of threads waiting
for a connection.
Avg wait time:
Indicates the average time
that a client waited to be
granted a connection.
Faults:
Indicates the rate at which
connection pool timeouts
occur.
Usage:
Indicates the average
percentage of connections
of the pool in use
Percent maxed:
Average percentage of the
time that all connections
are in use.
Prepared statement
cache discard rate:
Indicates the rate at which
the prepared statements
are discarded from the
cache.

3.1.3 The WebSphere EJB Layer
The WsBeans test shown in Figure 3.4 determines the status of the WebSphere EJB layer. This layer
determines the status of specific Enterprise Java Bean (abbreviated as EJB in this manual)
components hosted on a WebSphere server. The details of these tests are provided below:

201

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Figure 3.4: Tests mapping to the WebSphere EJB layer

3.1.3.1.1

Ws Beans Test

Enterprise Java Beans (EJB) forms the critical components of any business application. WebSphere
application server creates instances corresponding to the EJB. This test reports the performance
metrics that determines the functioning of the EJB groups. Use the Click here hyperlink in the test
configuration page to configure the EJB groups that need to be monitored by the eG Enterprise suite.

By default, the eG Enterprise system monitors only those EJBs that are part of a group.
Purpose

To measure the statistics pertaining to the Enterprise Java Bean groups configured
on the WebSphere application server.

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

202

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

number

through

which

the

WebSphere



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.

203

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).
If both (a) and (b) do not apply, specify none against CONNECTORPORT.

204

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

11. CONFIRM PASSWORD - If security has been enabled, confirm the specified
PASSWORD by retyping it in the CONFIRM PASSWORD text box. If the
WebSphere server does not require any authentication, then leave the
CONFIRM PASSWORD text box with its default setting.
12. ENCRYPTPASS – By default, this flag is set to YES, indicating that the
PASSWORD of the WebSphere server is encrypted by default. To disable
password encryption, select the NO option.
13. AUTODISCOVERY – By default, the eG suite allows administrators to configure
EJB groups using the eG administrative interface, and reports metrics
pertaining to every group so created. Accordingly, by default,
AUTODISCOVERY is set to NO. If you want EJBs to be discovered and
monitored automatically, then select the YES option against AUTODISCOVERY.
When this is done, the eG agent automatically discovers all the EJBs on the
WebSphere server, and reports one set of measures for every EJB hosted on
the server.
14. SERVERNAME – Specify the name of the WebSphere server instance to be
monitored. To know the instances of a WebSphere server currently available,
first, connect to the WebSphere Administrative console using the URL: http://\admin. Then,
login to the administrative console and expand the Servers node in the left
pane of the console. Next, click on the Application Servers sub-node under the
Servers node. A list of server instance Names and their corresponding Node
values will then be displayed in the right pane. One of the displayed server
instances can be specified as the value of the SERVERNAME parameter.
15. TIMEOUT - In the TIMEOUT text box, specify the maximum duration (in
seconds) for which the test will wait for a response from the application
server. The default TIMEOUT period is 60 seconds.
16. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the
eG Enterprise suite embeds an optional detailed diagnostic capability. With
this capability, the eG agents can be configured to run detailed, more
elaborate tests as and when specific problems are detected.
To enable the detailed diagnosis capability of this test for a particular server,
choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will
be available only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for every EJB group configured

Measurement

Measurement
Unit

205

Interpretation

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Bean instantiations:
This measure indicates the
rate at which the bean
objects are instantiated.

Bean destroys:
Indicates the rate at which
the bean objects are
destroyed.
Bean method calls:

S e r v e r s

Instances/S
ec

A sudden increase in the rate of
instantiations indicates a bottleneck
on the server. It may be due to
greater load on the server or there
might
be
a
loophole
in
the
application.

Instances/S
ec

A very low value indicates a
bottleneck on the server. This might
affect the performance of the
application.

Methods/Sec

A high value indicates that the server
is busy.

Secs

A sudden increase in the value of this
measure is a sign of overload on the
server.

Secs

This value should be low for optimal
performance
of
the
application
server. The value may go high, if
there are more objects in the pool,
which is a sign of overload. This
measure will not be available if the
instrumentation level is set to H,
instead of X.

Number

A large pool size signifies that some
of the objects are not being released
by the application.

This measure indicates the
rate at which the methods
are being processed by the
server.
Avg method rate:
This measure indicates the
average response time of
all methods of the remote
interface for this bean.
Avg bean creation time:
Indicates the average
method response time for
creates.

Bean pool size:
Indicates the average
number of objects in the
pool.

3.1.4 The WebSphere Web Layer
This layer tracks the health of all web applications and transactions that exist on the server. Figure 3.5
depicts the tests that map to this layer.

206

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Figure 3.5: Tests mapping to the WebSphere Web layer

3.1.4.1

WebSphereGlobalTransactions Test

Transactions are the key functionality of the WebSphere application server. Global transactions are
those that take place in more than one server. This test monitors the global transactions that are
happening on different servers.

Purpose

To measure the statistics pertaining to the global transactions that take place in a
WebSphere application server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

207

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

number

through

which

the

WebSphere



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.

208

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).
If both (a) and (b) do not apply, specify none against CONNECTORPORT.

209

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the test

One set of results for each WebSphere application server being monitored.

Measurement
Global transactions
begun:

Measurement
Unit

Interpretation

Trans/Sec

A high value indicates an overload on
the server.

Number

If the value of this measure is high, it
signifies greater load on the server.
This might increase the number of
waiting local transactions.

Secs

A high transaction duration value
indicates increased load on the
server.

Secs

If the total time taken for committing
a global transaction is high, then it
indicates a bottleneck on the server.

Indicates the rate at which
global transactions are
beginning to occur at the
server.
Active global
transactions:
Indicates the average
number of concurrently
active global transactions.
Global transaction
duration:
Indicates the average
duration of global
transactions.
Global commit duration:
Indicates the average
duration of commit for
global transactions.

210

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Optimization rate:

S e r v e r s

Trans/Sec

Indicates the rate at which
global transactions being
converted to single phase
for optimization.

A sudden increase in this value might
be caused due to one of the following
reasons.
a.

There might be more
number of requests for the
application.

b.
Global transaction
commits:

Transactions
/Sec

If the rate of transactions that are
being committed is very high, it
signifies load on the server. It might
be caused when some locked
transactions are released suddenly.

Trans/Sec

A high value indicates a problem with
the application. Possible reasons
could be the problem with the
application or with some other
dependent server (e.g. Database).

Trans/Sec

Again, a rise in the value could be
due to the problem with the
application or with some other
dependent server like the database.

Number

A sudden increase in the value might
be caused if the commit duration of a
transaction goes low.

Secs

A high value indicates a bottleneck
on the server.

Indicates the rate at which
global transactions are
being committed.
Global transaction
rollbacks:
Indicates the rate at which
the global transactions are
being rolled back.
Global transaction
timeouts:
Indicates the rate at which
the global transactions are
being timed out.
Global transactions
involved:
Indicates the total number
of global transactions
involved at the server.
Global prepare duration:
This measure indicates the
average duration of
prepare for the global
transactions.

3.1.4.2

There might be a bottleneck
on the application.

WebSphere Local Transactions Test

Local transactions are those transactions that occur within the server. This test reports all the
performance metrics associated with the local transactions.

Purpose

To measure the statistics pertaining to the local transactions that take place in a
WebSphere application server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

211

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

number

through

which

the

WebSphere



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.

212

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).
If both (a) and (b) do not apply, specify none against CONNECTORPORT.

213

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the test

One set of results for each WebSphere application server being monitored.

Measurement
Local transaction begin
rate:

Measurement
Unit

Interpretation

Transactions
/Sec

A high value indicates an increased
overload on the server.

Number

If the value of this measure is high, it
signifies greater load on the server.
This might increase the number of
waiting local transactions.

Secs

A high transaction duration value
indicates increased load on the
server.

Secs

If the total time taken for committing
a local transaction is high, then it
indicates a bottleneck on the server.

Indicates the rate at which
the local transactions begin
at the server.
Active local
transactions:
Indicates the average
number of concurrently
active local transactions.
Local transaction
duration:
Indicates the average
duration of the local
transactions.
Local commit duration:
Indicates the average
duration of commit for
local transactions.

214

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Local transaction
commits:

S e r v e r s

Trans/Sec

If the rate of transactions that are
being committed is very high, it
signifies load on the server. It might
be caused when some locked
transactions are released suddenly.

Trans/Sec

A high value indicates a problem with
the application. Possible reasons
could be the problem with application
or with some other dependent server
(e.g. Database).

Trans/Sec

Again, a rise in the value could be
due to the problem with the
application or with some other
dependent server like the database.

Indicates the rate at which
the local transactions are
being committed.
Local transaction
rollbacks:
Indicates the rate at which
the local transactions are
being rolled back.
Local transaction
timeouts:
Indicates the rate at which
the local transactions are
being timed out.

3.1.4.3

WebSphere Servlet Sessions Test

Http sessions form a part of any business application. This test monitors the http sessions on the
WebSphere application server.

Purpose

To measure the statistics pertaining to the servlet sessions in a WebSphere
application server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

215

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

number

through

which

the

WebSphere



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.

216

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).
If both (a) and (b) do not apply, specify none against CONNECTORPORT.

217

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the test

One set of results for each WebSphere application server being monitored.

Measurement
Session creation rate:
Indicates the rate at which
the sessions are created in
the server.

Invalidated sessions:

Measurement
Unit
Sessions/Se
c

A high value indicates a high level of
activity in this application. By
observing the variations to this
measure
over
time,
you
can
determine usage trends such as the
time of day when an application is
getting the most amount of traffic.

Number

This message is indicative of the
session usage pattern of this
application.

Secs

A long session lifetime may occur due
to one of the following reasons:

Indicates the number of
sessions that were
invalidated.
Session life time:

Interpretation

This measure indicates the
average lifetime of a
session.

218

The application may not
timeout the sessions after a
fixed interval of time.

The
sessions
in
the
application might be active
for a very long time.

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Active sessions:

S e r v e r s

Number

A high value indicates an increased
workload on the server.

Number

A high value indicates an increased
workload on the server.

This measure indicates the
total number of sessions
that currently are being
accessed by the requests.
Live sessions:
Indicates the total number
of valid sessions on the
server.

3.1.4.4

WebSphere Web Applications Test

A web application is a collection of different web components such as servlets, JSPs etc. This test
tracks the statistics pertaining to the web applications hosted on the WebSphere application server.

Purpose

To measure the statistics pertaining to the web applications that exist in the
WebSphere application server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

219

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

number

through

which

the

WebSphere



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.

220

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).
If both (a) and (b) do not apply, specify none against CONNECTORPORT.

221

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the test

One set of results for each web application that is deployed in the WebSphere
application server being monitored.

Measurement
Loaded servlets:

Measurement
Unit
Number

A sudden increase in the number of
loaded servlets indicates an increase
in the load on the server or for that
particular application.

Number

It is preferable to have minimum
reloads for optimal performance of
the application.

Reqs/Sec

An increase in the request rate
indicates an increase in the server
load.

Number

An increase in the value of this
measure indicates an increase in the
user workload. It may also increase
due to the overload on the server.

Indicates the current
number of loaded servlets.
Reloads:
Indicates the number of
times the servlet is being
reloaded.
Requests:
Indicates the total number
of requests for the
servlets.
Concurrent requests:

Interpretation

Number of requests that
are concurrently being
processed.

222

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Avg response time:

S e r v e r s

Secs

Indicates the time taken
for the completion of the
requests.

An increasing value indicates a
bottleneck on the server. This may
arise due to one of the following
reasons:
1.The server might be running out of
resources.
2. The server may be overloaded
with requests.
3. Some problem with the available
bandwidth on the network.

Errors:

Errors/Sec

Indicates the rate at which
errors or exceptions are
occurring in the servlets.

3.1.4.5

A high rate of errors might occur due
to too many requests on the
application or there might be a
bottleneck on the application.

WebSphere ORB Summary Test

This test reports statistics pertaining to the ORBs (Object Request Broker) on a WebSphere server.

Purpose

To report statistics pertaining to the ORBs (Object Request Broker) on a
WebSphere server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

223

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

number

through

which

the

WebSphere



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.

224

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).
If both (a) and (b) do not apply, specify none against CONNECTORPORT.

225

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the test

One set of results for each server instance being monitored

Measurement
Reference lookup time:

Measurement
Unit
Secs

The amount of time taken
to
lookup
an
object
reference before method
dispatch can be carried
out.
Total requests:

Interpretation
An excessively long time may
indicate an EJB container lookup
problem.

Number

Indicates the total number
of requests sent to the
ORB.
Concurrent requests:

Number

Indicates the number of
requests that are
concurrently processed by
the ORB.
Avg processing time:

Secs

Indicates the time it takes
a registered portable
interceptor to run.

3.1.4.6

WebSphere Web Applications Summary Test

This tes t reports statistics pertaining to the web applications deployed on a WebSphere server.
226

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Purpose

To report statistics pertaining to the web applications deployed on a WebSphere
server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Configurable
parameters for
the test

number

through

which

the

WebSphere



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.

227

M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

8. In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify none
here.
9. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).
If both (a) and (b) do not apply, specify none against CONNECTORPORT.

228

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

10. USER - If security has been enabled for the WebSphere server being
monitored, then provide a valid USER name to login to the WebSphere server.
If the WebSphere server does not require any authentication, then the USER
text box should contain the default value 'none'.
11. PASSWORD – If security has been enabled for the WebSphere server being
monitored, then provide the PASSWORD that corresponds to the specified
USER name. If the WebSphere server does not require any authentication,
then leave the PASSWORD text box with its default setting.
12. CONFIRM PASSWORD - If security has been enabled, confirm the specified
PASSWORD by retyping it in the CONFIRM PASSWORD text box. If the
WebSphere server does not require any authentication, then leave the
CONFIRM PASSWORD text box with its default setting.
13. ENCRYPTPASS – By default, this flag is set to YES, indicating that the
PASSWORD of the WebSphere server is encrypted by default. To disable
password encryption, select the NO option.
14. SERVERNAME – Specify the name of the WebSphere server instance to be
monitored. To know the instances of a WebSphere server currently available,
first, connect to the WebSphere Administrative console using the URL: http://\admin. Then,
login to the administrative console and expand the Servers node in the left
pane of the console. Next, click on the Application Servers sub-node under the
Servers node. A list of server instance Names and their corresponding Node
values will then be displayed in the right pane. One of the displayed server
instances can be specified as the value of the SERVERNAME parameter.
15. TIMEOUT - In the TIMEOUT text box, specify the maximum duration (in
seconds) for which the test will wait for a response from the application
server. The default TIMEOUT period is 60 seconds.

Outputs of the
test
Measurements
made by the test

One set of results for each server instance being monitored

Measurement
Loaded servlets:

Measurement
Unit
Number

Indicates the number of
servlets that were loaded.
Reloads:

Number

Indicates the number of
servlets that were
reloaded.
Total requests:

Number

Indicates the number of
requests that the servlets
have processed.

229

Interpretation

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Concurrent requests:

S e r v e r s

Number

Indicates the number of
requests that the servlets
have concurrently
processed.
Avg response time:

Secs

Indicates the time it takes
for a servlet request to be
serviced.
Total errors:

Number

Indicates the total number
of errors in the servlet/JSP.

3.1.4.7

WebSphere Web Server Summary Test

This test reports statistics pertaining to the web services mounted on a WebSphere server.

Purpose

To report statistics pertaining to the web services mounted on a WebSphere
server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

230

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

number

through

which

the

WebSphere



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER parameter is applicable only under the
following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.



In the case of situation (b), enter the SERVERHOSTNAME itself as the
NDMANAGER. If both conditions (a) and (b) do not apply, then specify
none here.

231

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

8. CONNECTORPORT - The CONNECTORPORT parameter is applicable only under
the following circumstances:
a.

If the WebSphere server being monitored belongs to a cluster, or,

If the WebSphere server being monitored is one of many
instances of the server running on the same host



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



In case of situation (b), do the following to know the CONNECTORPORT:



Expand the Servers node in the tree-structure in the left pane of the
console, and click on the Application Servers link. A list of application server
instances will then appear in the right pane.



Click on the server instance being monitored. Doing so invokes the
Configuration of the chosen server instance appears.



Scroll down the Configuration to view the End Points link. Once you locate the
End Points link, click on it.



In the page that appears next, click on the SOAP_CONNECTOR_ADDRESS link.



The Port displayed in that page should be used as the CONNECTORPORT in
situation (b).
If both (a) and (b) do not apply, specify none against CONNECTORPORT.

232

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the test

One set of results for each server instance being monitored

Measurement
Loaded services:

Measurement
Unit
Number

Indicates the number of
web services loaded by the
application server.
Requests received:

Number

Indicates the number of
requests received by the
web services.
Requests dispatched:

Number

Indicates the number of
requests dispatched by the
service to a target code.
Requests successful:

Number

Indicates the number of
requests that were
successfully responded to.
Avg response time:

Secs

Indicates the average time
between
receipt
of
a
request and the dispatch of
a response.

233

Interpretation

M o n i t o r i n g

3.1.4.8

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

WebSphere ORB Test

This test reports statistics pertaining to each of the ORBs (Object Request Broker) on a WebSphere
server.

Purpose

To report statistics pertaining to each of the ORBs (Object Request Broker) on a
WebSphere server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

234

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

number

through

which

the

WebSphere



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. NDMANAGER - The NDMANAGER and CONNECTORPORT parameters will be
applicable only if the WebSphere application server being monitored is part of
a cluster. If so, then, in the NDMANAGER text box, provide the host name of
the node manager that manages the application servers in the cluster. If the
WebSphere server being monitored does not belong to a cluster, then specify
none in this text box. To know the name of the node manager, do the
following:



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

235

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

8. CONNECTORPORT - The port using which the node manager communicates
with the WebSphere servers in the cluster will have to be specified in the
CONNECTORPORT text box. If the server being monitored is not part of a
cluster, then specify none here. The connector port can be a SOAP port or an
RMI port. To know the port number, do the following:



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



Two entries that read as follows will be present in the wsadmin.properties
file:
com.ibm.ws.scripting.port=
#com.ibm.ws.scripting.port=

Both the entries will have port numbers against them. However, the
uncommented entry (the entry without the #) is the one that denotes an
active port. Therefore, specify the corresponding port number as the
CONNECTORPORT.
9. USER - If security has been enabled for the WebSphere server being
monitored, then provide a valid USER name to login to the WebSphere server.
If the WebSphere server does not require any authentication, then the USER
text box should contain the default value 'none'.
10. PASSWORD – If security has been enabled for the WebSphere server being
monitored, then provide the PASSWORD that corresponds to the specified
USER name. If the WebSphere server does not require any authentication,
then leave the PASSWORD text box with its default setting.
11. CONFIRM PASSWORD - If security has been confirm the specified PASSWORD
by retyping it in the CONFIRM PASSWORD text box. If the WebSphere server
does not require any authentication, then leave the CONFIRM PASSWORD text
box with its default setting.
12. ENCRYPTPASS – By default, this flag is set to YES, indicating that the
PASSWORD of the WebSphere server is encrypted by default. To disable
password encryption, select the NO option.
13. SERVERNAME – Specify the name of the WebSphere server instance to be
monitored. To know the instances of a WebSphere server currently available,
first, connect to the WebSphere Administrative console using the URL: http://\admin. Then,
login to the administrative console and expand the Servers node in the left
pane of the console. Next, click on the Application Servers sub-node under the
Servers node. A list of server instance Names and their corresponding Node
values will then be displayed in the right pane. One of the displayed server
instances can be specified as the value of the SERVERNAME parameter.
14. TIMEOUT - In the TIMEOUT text box, specify the maximum duration (in
seconds) for which the test will wait for a response from the application
server. The default TIMEOUT period is 60 seconds.

Outputs of the
test

One set of results for each server instance being monitored

236

M o n i t o r i n g

Measurements
made by the test

W e b S p h e r e

A p p l i c a t i o n

Measurement
Avg processing time:

S e r v e r s

Measurement
Unit
Secs

Indicates the time this
registered
portable
interceptor takes to run.

3.1.4.9

Interpretation
A high processing time is indicative of
a performance bottleneck.

WebSphere Web Server Test

This test reports statistics pertaining to each of the web services mounted on a WebSphere server.

Purpose

To report statistics pertaining to each of the web services mounted on a
WebSphere server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

237

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

number

through

which

the

WebSphere



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Using the tree-structure in the left pane of the Administrative Console that
appears, drill down to the Deployment Manager node within System
Administration.



Select the Configuration tab that appears in the right pane, and scroll down
to the End Points link in the Additional Properties section.



Once you locate the End Points link, click on it, and in the page that
appears, click on the SOAP_CONNECTOR_ADDRESS link.



In the subsequent page, a fully qualified domain name will be displayed
against Host. This is the name that should be specified as the host name of
the node manager in the NDMANAGER text box.

238

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



From

the

Node

manager's

host,

open

the

\DeploymentManager\properties\wsadmin.properties
file.



9. USER - If security has been enabled for the WebSphere server being
monitored, then provide a valid USER name to login to the WebSphere server.
If the WebSphere server does not require any authentication, then the USER
text box should contain the default value 'none'.
10. PASSWORD – If security has been enabled for the WebSphere server being
monitored, then provide the PASSWORD that corresponds to the specified
USER name. If the WebSphere server does not require any authentication,
then leave the PASSWORD text box with its default setting.
11. CONFIRM PASSWORD - If security has been confirm the specified PASSWORD
by retyping it in the CONFIRM PASSWORD text box. If the WebSphere server
does not require any authentication, then leave the CONFIRM PASSWORD text
box with its default setting.
12. ENCRYPTPASS – By default, this flag is set to YES, indicating that the
PASSWORD of the WebSphere server is encrypted by default. To disable
password encryption, select the NO option.
13. SERVERNAME – Specify the name of the WebSphere server instance to be
monitored. To know the instances of a WebSphere server currently available,
first, connect to the WebSphere Administrative console using the URL: http://\admin. Then,
login to the administrative console and expand the Servers node in the left
pane of the console. Next, click on the Application Servers sub-node under the
Servers node. A list of server instance Names and their corresponding Node
values will then be displayed in the right pane. One of the displayed server
instances can be specified as the value of the SERVERNAME parameter.
14. TIMEOUT - In the TIMEOUT text box, specify the maximum duration (in
seconds) for which the test will wait for a response from the application
server. The default TIMEOUT period is 60 seconds.

Outputs of the
test

One set of results for each web service on the monitored WebSphere server
instance

239

M o n i t o r i n g

Measurements
made by the test

W e b S p h e r e

A p p l i c a t i o n

Measurement
Loaded services:

S e r v e r s

Measurement
Unit

Interpretation

Number

Indicates the number of
instances of this web
service that have been
loaded by the application
server.
Requests received:

Number

Indicates the number of
requests received by this
web service.
Requests dispatched:

Number

Indicates the number of
requests dispatched by this
web service to a target
code.
Requests successful:

Number

Indicates the number of
requests
that
were
succesfully responded to
by this web service.
Avg response time:

Secs

Indicates the average time
between
receipt
of
a
request and the dispatch of
a response by this web
service.

3.2 Monitoring the WebSphere Application Server 6.0 (and
above)
As the WebSphere server 6.0 (and above) supports different capabilities and interfaces than the
earlier versions, the eG Enterprise suite offers a different monitoring model for WebSphere 6.0 (and
above). In the case of the WebSphere application server version 6.0 and above, the eG agent uses the
JMX architecture supported by the WebSphere server to gather the required metrics.
To monitor a WebSphere Application server 6.0 (and above), a specific WebSphere monitoring eG
component has to be installed on it. If the WebSphere server to be monitored uses a SOAP connector
port for its internal communications, then the egurkha6.ear application (in the /opt/egurkha/lib or the
\lib directory) will have to be installed on the server. On the other hand, if the target
WebSphere server uses an RMI port for communicating internally, then the egurkha6rmi.ear application
should be installed on the server. The procedure for installing the 'ear' file has been discussed in detail
in the eG Implementer's Guide.

240

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

The measures extracted by egurkha6.ear or egurkha6rmi.ear (as the case may be) are captured and
displayed by the unique monitoring model that eG Enterprise prescribes for the WebSphere
Appolication server 6.0 (and above) (see Figure 3.6).

Figure 3.6: Layer model of the WebSphere Application server 6.0 (or above)
The tests executing on each of the layers depicted by Figure 3.6 extract a wealth of performance data
from the WebSphere application server, that enable WebSphere administrators to determine the
following:



Does EJB creation take too long?



Was the WebSphere cache adequately sized, or were there too many cache misses?



Is sufficient memory allotted to the WebSphere JVM?



Is the thread pool adequately sized?



Did too many connections in the database connection pool timeout?



Are transaction rollbacks happening too frequently on the server?



Are transactions taking too long to complete?



How many synchronous/asynchronous requests were processed by the WebSphere gateway?



How well does the ORB (Object Request Broker) handle requests for objects received by it?



Were any errors detected during JSP/servlet processing?



Are the web services executing on the WebSphere server too slow in responding to requests
received by it?

The sections to come will elaborate on the tests associated with the top 5 layers only.

3.2.1 The JVM Layer
By default, no tests are mapped to the JVM layer of the WebSphere Application server 6.0 (or above).
This is because, all tests reporting critical JVM-related metrics are disabled by default for the
WebSphere server. To enable one/more of these tests, open the AGENTS – TESTS CONFIGURATION page
using the Agents -> Tests -> Configure menu sequence, select WebSphere Application from the

241

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Component type list, scroll down the test list that appears to view the DISABLED TESTS section, select the
check box corresponding to the JVM test of interest to you, and then, click the Update button.
If all the JVM tests are enabled, then clicking on the JVM layer will display the test list depicted by
Figure 3.7 below.

Figure 3.7: The tests mapped to the JVM layer
These tests collectively report the resource usage and overall health of the WebSphere JVM. The
JvmGarbageCollection test has been elaborately discussed in Section 3.1.1 above, and all the other
tests have been dealt with in Chapter 0 of this document.

3.2.2 The WAS Service Layer
Using the tests associated with the WAS Service layer, the eG agents can closely observe the
performance of the following critical services executing on the WebSphere Application server:



Cache management



Object pools



Garbage collection (GC)



Thread pools

242

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Figure 3.8: The tests associated with the WAS Service layer

3.2.2.1

WAS Cache Test

The WASCache test monitors the cache usage on the WebSphere server.

Purpose

Monitors the cache usage on the WebSphere server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

243

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST – The IP address of the WebSphere application server
3. PORT – The port number of the WebSphere application server
4. SERVERHOSTNAME – Specify the host name of the application server instance
being monitored.
5. APPPORT – Specify the port number to be used for accessing the egurkha
application that has been deployed on the server.
6. NODENAME - Specify the node name of the server instance being monitored.
To know the node name, do the following



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



A list of application server instances and their corresponding node names
will then appear in the right pane of the console. From this list, you can
figure out the Node that corresponds to the application server instance
being monitored, and specify that name against the NODENAME parameter.

7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



A list of application server instances and their corresponding node names
will then appear in the right pane of the console. From this list, you can
figure out the Name of the monitored server instance, and specify that
name against the SERVERNAME parameter.

If the server instance being monitored is part of a WebSphere cluster, then
you need to provide the host name that corresponds to the connector port of
the Deployment Manager of the cluster as the SERVERNAME. To determine
the SERVERNAME in this case, do the following:



Connect to the WebSphere Administrative console using the URL: http://\admin > or

https://\admin>.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

244

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



If the SOAP port has been set as the connector port in your environment,
then scroll down the page that appears next until you view the Port Name,
SOAP_CONNECTOR_ADDRESS. Make note of the Host name that corresponds to
this port name. If the RMI port is the connector port in your environment,
then make note of the Host name that corresponds to the Port name,
BOOTSTRAP_ADDRESS.



Specify this Host name as the SERVERNAME.

8. CONNECTORPORT - The applications that are deployed on a server instance
use the CONNECTORPORT for all internal communications with the application
server. The connector port can be a SOAP port or an RMI port. The default
connector port however, is the SOAP port. To know the connector port
number, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



A list of application server instances and their corresponding node names
will then appear in the right pane of the console. In the right pane, click
on the server name link that corresponds to the server instance that is
being monitored.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Expand the Ports link in this section to view a list of ports. If the default
connector port is in use, then the port number displayed against
SOAP_CONNECTOR_ADDRESS should be specified as the CONNECTORPORT. If
an RMI port has been explicitly set as the connector port, then specify the
port
number
displayed
against
BOOTSTRAP_ADDRESS
as
the
CONNECTORPORT.

If the server instance being monitored is part of a WebSphere cluster, then
you need to provide the SOAP/RMI port of the Deployment Manager of the
cluster as the CONNECTORPORT. To determine the CONNECTORPORT in this
case, do the following:



Connect to the WebSphere Administrative console using the URL: http://\admin > or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.
245

M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

A list of ports will then appear. If the default connector port is in use, then
the port number displayed against SOAP_CONNECTOR_ADDRESS should be
specified as the CONNECTORPORT. If an RMI port has been explicitly set
as the connector port, then specify the port number displayed against
BOOTSTRAP_ADDRESS as the CONNECTORPORT.

9. SSL - Select Yes if SSL (Secured Socket Layer) is to be used to connect to the
WebSphere server, and No if it is not.
10. USER - If security has been enabled for the WebSphere server being
monitored, then provide a valid USER name to login to the WebSphere server.
If the WebSphere server does not require any authentication, then the USER
text box should contain the default value 'none'.
11. PASSWORD – If security has been enabled for the WebSphere server being
monitored, then provide the PASSWORD that corresponds to the specified
USER name. If the WebSphere server does not require any authentication,
then leave the PASSWORD text box with its default setting.
12. CONFIRM PASSWORD - If security has been enabled, confirm the specified
PASSWORD by retyping it in the CONFIRM PASSWORD text box. If the
WebSphere server does not require any authentication, then leave the
CONFIRM PASSWORD text box with its default setting.

Outputs of the
test
Measurements
made by the test

One set of results for each cache on the server instance being monitored

Measurement
Client requests:

Measurement
Unit

Interpretation

Number

Indicates the number of
requests
for
cacheable
objects
that
were
generated by applications
running on the application
server, since the last
measurement period.
Explicit invalidation:

Number

Indicates the number of
explicit invalidations since
the last measurement
period.
Hits on memory:

Number

Indicates the number of
requests for cacheable
objects that were served
from memory since the
last measurement period.

246

While direct disk reads cause an
increase in processing overheads,
memory reads are less expensive.
Therefore, a high value of this
measure is indicative of the good
health of the server.

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Hits on disk:

S e r v e r s

Number

Indicates the number of
requests for cacheable
objects that are served
from the disk since the last
measurement period.
Memory cache entry:

Reading from the disk is more
expensive than reading from the
cache. Therefore, ideally, this value
should be low.

Number

Indicates the number of inmemory
cache
entries
since
the
last
measurement period.
Max memory cache
entry:

Number

Indicates the maximum
number
of
in-memory
cache entries.
Miss count:

Number

Indicates the number of
requests
for
cacheable
objects that were not
served from the cache
since
the
last
measurement period.
Remote creations:

Number

Indicates the number of
cache entries that were
received from co-operating
dynamic caches, since the
last measurement period.
Remote hits:

Number

Indicates the number of
requests
for
cacheable
objects that were served
from other JVMs within the
replication domain, since
the
last
measurement
period.
Timeout invalidations:

Number

Indicates the number of
cache entries that were
removed from the memory
and disk because of a
timeout, since the last
measurement period.

247

Ideally, this value should be low.

M o n i t o r i n g

3.2.2.2

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

WAS JVM Test

The WASJVM test monitors the usage of the WebSphere JVM heap.

Note:
To enable the test to collect metrics related to the garbage collection and thread activity, you
should enable the Java Virtual Machine Tool Interface (JVMTI) of the WebSphere Server.

Purpose

Monitors the usage of the WebSphere JVM heap

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

248

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin > or

https://\admin>.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

249

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin > or

https://\admin>.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Free memory:

Measurement
Unit
MB

A very low value of this measure is
indicative of excessive memory
utilization in the JVM.

A high value of this measure
indicates a heavy workload on the
WebSphere application server. In
such a case, you might want to
consider increasing the JVM heap
size.

Number

If adequate memory is not allotted to
the JVM, then the value of this
measure would be very high. A high
value of this measure is indicative of
a high frequency of GC. This is not a
good sign, as GC, during its
execution, has the tendency of
suspending an application, and a
high frequency of GC would only
adversely impact the application's
performance. To avoid this, it is
recommended
that
you
allot
sufficient memory to the JVM.

Indicates the amount of
memory currently available
in the JVM.
Used memory:
Indicates the amount of
memory that has been
currently utilized by the
JVM.
GC count:

Interpretation

Indicates the number of
GC calls since the last
measurement period.

251

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Percent gc time:

S e r v e r s

Percent

If adequate memory is not allotted to
the JVM, then the value of this
measure would be very high. This is
not a good sign, as GC, during its
execution, has the tendency of
suspending an application, and a
high value of this measure would
only
adversely
impact
the
application's performance. To avoid
this, it is recommended that you allot
sufficient memory to the JVM.

Percent

A high value of this measure
indicates a heavy workload on the
WebSphere application server. In
such a case, you might want to
consider increasing the JVM heap
size.

Indicates the percentage of
time spent on GC.

Percent heap used:
Indicates the percentage of
heap memory utilized by
the JVM.

Objects allocated:

Number

Indicates the number of
objects allocated in the
heap
since
the
last
measurement period.
Objects freed:

Number

Indicates the number of
objects freed in the heap
since
the
last
measurement period.
Objects moved:

Number

Indicates the number of
objects in the heap since
the
last
measurement
period.
Threads started:

Number

Indicates the number of
threads started since the
last measurement period.
Threads ended:

Number

Indicates the number of
threads that ended since
the
last
measurement
period.
Waits for lock:

Number

Indicates the number of
times a thread waits for a
lock,
since
the
last
measurement period.

252

A high value is indicative of high
server workload.

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Wait for lock time:

S e r v e r s

Secs

Indicates the average time
a thread waits for a lock.

3.2.2.3

WAS Object Pools Test

The WASObjectPools test reports critical statistics pertaining to the object pools on the WebSphere
server.

Purpose

Reports critical statistics pertaining to the object pools on the WebSphere server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

253

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin > or

https://\admin gin to the WebSphere Administrative console


Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

254

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin > or

https://\admin >.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Objects created:

Measurement
Unit

Interpretation

Number

Indicates the number of
new objects created by the
object pool, since the last
measurement period.
Objects allocated:

Number

Indicates the current count
of objects allocated by the
object pool.
Objects returned:

Number

Indicates the current count
of objects returned to the
pool.
Idle objects:

Number

Indicates the current count
of idle objects.

3.2.2.4

WAS Threads Test

To optimize performance and at the same time to support concurrent accesses from users, the
application server uses thread pools. It is critical to monitor a WebSphere server's thread pools on an
ongoing basis. This test monitors the thread pools on a WebSphere server.

256

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Purpose

Monitors the thread pools on a WebSphere server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Configurable
parameters for
the test



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

257

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Active count:

Measurement
Unit
Number

Indicates the number of
threads that are currently
active.

Interpretation
A high value for this measure is
indicative of a high load on this
application and combined with the
creation and destroy rates might give
insights of the application pattern.
This measure is also useful for
determining
usage
trends.
For
example, it can show the time of day
and the day of the week in which you
usually reach peak thread count. In
addition, the creation of too many
threads can result in out of memory
errors or thrashing. By watching this
metric, you can reduce excessive
memory consumption before it’s too
late.

Create count:

Number

A sudden increase in the value of this
measure directly relates to an
increase in the activity happening in
this application.

Number

A decrease in the value of this
measure indicates that the threads
are being active for a long period of
time, which might indicate anomalies
within the application.

Indicates the number of
threads that were created
since the last
measurement period.
Destroy count:
Indicates the number of
threads that were
destroyed since the last
measurement period.

259

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Pool size:

S e r v e r s

Number

Indicates the number of
threads in the pool,
currently.
Threads hung count:

If the pool size is high and the
number of active threads is low, it
signifies that the threads are not
being destroyed immediately after
use.

Number

Indicates the number of
concurrently stopped
threads.

3.2.3 The WAS Database Layer
The WAS Database layer monitors the connection pools on the WebSphere application server.

Figure 3.9: The test associated with the WAS Database layer

3.2.3.1

WAS Connection Pools Test

The WASConnPoolTest monitors the usage of the connection pools on the WebSphere server.

Purpose

Monitors the usage of the connection pools on the WebSphere server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Outputs of the
test

One set of results for each connection pool being monitored

260

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

261

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin > or

https://\admin>.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Allocate count:

Measurement
Unit

Interpretation

Number

Indicates the number of
connections allocated to
the pool during the last
measurement period.
Close count:

Number

Ideally, this value should be low.

Indicates the number of
connections released from
the pool during the last
measurement period.
Create count:

Number

Indicates the number of
connections created during
the last measurement
period.
Fault count:

Number

Ideally, this value should be low. An
unusually high value could indicate
an application leak.

Number

A very low value of this measure
could result in a shortage of
connections in the pool.

Indicates the number of
connection timeouts in the
pool in the last
measurement period.
Freed count:
Indicates the number of
connections that were
returned to the pool in the
last measurement period

263

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Free pool size:

S e r v e r s

Number

Indicates the current
number of free connections
in the pool.
Pool size:

Number

Indicates the current size
of the connection pool.
Jdbc time:

Secs

A low value is ideal.

Indicates the time taken
by the JDBC queries to
execute.

3.2.4 The WAS EJB Layer
The WAS EJB layer extracts critical performance statistics pertaining to the following:



The EJBs deployed on the WebSphere application server



The Http sessions on the server



The global and local transactions executing on the WebSphere application server

Figure 3.10: The tests associated with the WAS EJB layer

3.2.4.1

WAS Beans Test

The WASBeans test automatically discovers the EJBs deployed on the WebSphere server and reports
critical statistics pertaining to each of the EJBs.

Purpose

Automatically discovers the EJBs deployed on the WebSphere server and reports
critical statistics pertaining to each of the EJBs

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

264

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

265

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the test

One set of results for each EJB deployed on the WebSphere application server

Measurement
Create count:

Measurement
Unit

Interpretation

Number

Indicates the number of
times this EJB was created
during
the
last
measurement period.
Avg create time:

Secs

Indicates the average time
taken by a bean create
call.
Remove count:

Number

Indicates the number of
times this bean was
removed during the last
measurement period.
Avg remove time:

Secs

Indicates the average time
taken by a bean remove
call.

267

Ideally, this value should be low.

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Activation count:

S e r v e r s

Number

Indicates the number of
times this bean was
activated during the last
measurement period.
Avg activation time:

Secs

Ideally, this value should be low.

Indicates the average time
taken by a bean activate
call, including the time at
the database.
Store count:

Number

Indicates the number of
times this bean was stored
in the persistent storage
during the last
measurement period.
Avg store time:

Secs

Indicates the average time
for storing this bean in a
persistent storage.
Instantiates count:

Number

A sudden increase in the number of
instantiations indicates a bottleneck
on the server. It may be due to
greater load on the server or there
might
be
a
loophole
in
the
application.

Number

A very low value indicates a
bottleneck on the server. This might
affect the performance of the
application.

Number

Greater the
better
will
performance.

Indicates the number of
times this bean was
instantiated during the last
measurement period.
Freed count:
Indicates the number of
times during the last
measurement period this
bean object was freed.
Ready count:
Indicates the number of
concurrently ready beans.
Passive count:

Number

Indicates the number of
beans in the passivated
state during the last
measurement.
Pooled count:

Number

Indicates the number of
objects currently in the
pool.

268

ready beans count,
be
the
application

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Drains count:

S e r v e r s

Number

Indicates the number of
times during the last
measurement period the
daemon found the pool
was idle and attempted to
clean it.
Retrieve count:

Number

Indicates the number of
calls during the last
measurement period
retrieving an object from
the pool.
Retrieve success count:

Number

Indicates the number of
times a retrieve found an
object in the pool, during
the last measurement
period.
Returns count:

Number

Indicates the number of
calls returning an object to
the pool, during the last
measurement period.
Returns discard count:

Number

Ideally, this value should be low. A
consistent high value could indicate a
full pool, and consequently, an
overloaded server. You might then
want to consider resizing the pool in
order to accommodate more number
of objects.

Number

A high value indicates that the server
is busy.

Secs

This value should be low for optimal
performance
of
the
application
server. The value may go high, if
there are more objects in the pool,
which is a sign of overload.

Indicates the number of
times during the last
measurement period the
returning object was
discarded because the pool
was full.
Methods call count:
Indicates the number of
method calls during the
last measurement period.
Methods response time:
Indicates the average
response time of the bean
methods.
Avg passivate time:

Secs

The average time taken by
a bean passivate call,
including the time at the
database

269

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Load count:

S e r v e r s

Number

The number of times this
bean was loaded from the
persistent storage during
the last measurement
period
Avg load time:

Secs

Ideally, this value should be low.

The average time for
loading a bean data from
the persistent storage

3.2.4.2

WAS Sessions Test

HTTP sessions form a part of any business application. This test monitors the HTTP sessions on the
WebSphere application server.

Purpose

Monitors the HTTP sessions on the WebSphere application server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Outputs of the
test

One set of results for each session on the WebSphere application server

270

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

271

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Active count:

Measurement
Unit
Number

A high value indicates an increased
workload on the server.

Number

A high value indicates an increased
workload on the server.

Number

A high value indicates a high level of
activity in this application.

Number

This measure is indicative of the
session usage pattern of this
application.

Indicates the number of
sessions that are currently
accessed by requests.
Live count:
Indicates the number of
sessions that are currently
live.
Create count:
Indicates the number of
sessions that were newly
created since the last
measurement period.
Invalidate count:

Interpretation

Indicates the number of
sessions that were
invalidated since the last
measurement period.

273

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Invalid session
requests:

S e r v e r s

Number

Indicates the number of
requests that were
received since the last
measurement period, for a
session that no longer
exists.
Cache discards:

Number

Indicates the number of
session objects that were
forced out of the cache.
New session failures:

Number

Indicates the number of
times since the last
measurement period, the
request for a new session
could not be handled
because the value
exceeded the maximum
session count

Timeout invalidates:

A consistent high value of this
measure could indicate that many
sessions have been alive for too long
a time. A long session lifetime may
occur due to one of the following
reasons:



The application may not
timeout the sessions after a
fixed interval of time.



The
sessions
in
the
application might be active
for a very long time.

Number

Indicates the number of
sessions that were
invalidated since the last
measurement period, due
to timeouts.

3.2.4.3

WAS Transactions Test

Transactions are the key functionality of the WebSphere application server. The WASTransactions test
monitors these transactions.

Purpose

Monitors the transactions on the WebSphere application server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Outputs of the
test

One set of results for each transaction on the WebSphere application server

274

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

275

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Active count:

Measurement
Unit
Number

If the value of this measure is high, it
signifies greater load on the server.
This might increase the number of
waiting transactions.

Number

If the number of transactions that
are being committed is very high, it
signifies load on the server. It might
be caused when some locked
transactions are released suddenly.

Number

A high value indicates a problem with
the application or with some other
(e.g. Database).

Number

A high value indicates an overload on
the server.

Number

A rise in the value could be due to
the problem with the application or
with some other dependent server
like the database.

Indicates the number of
concurrently
active
transactions.
Commits count:
Indicates the number of
transactions that were
committed since the last
measurement period.
Rollback count:
Indicates the number of
transactions that were
rolled back since the last
measurement period.
Begun count:
Indicates the number of
transactions that were
started on the server since
the last measurement
period.
Timedout count:

Interpretation

Indicates the number of
transactions that timed out
since the last
measurement period.

277

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Transaction time:

S e r v e r s

Secs

Indicates the average
duration of the
transactions.

A high transaction duration value
indicates increased load on the
server.

3.2.5 The WAS Web Layer
The tests associated with the WAS Web layer monitor the web-based components operating on the
WebSphere application server, such as:



the web applications deployed on the WebSphere application server



the synchronous and asynchronous requests received by WebSphere application server



the Object Request Brokers (ORB)



the web services mounted on a WebSphere server

Figure 3.11: The tests associated with the WAS Web layer

3.2.5.1

WAS Web Applications Test

The WASWebApplications test reports statistics pertaining to the web applications deployed on a
WebSphere server.

Purpose

Reports statistics pertaining to the web applications deployed on a WebSphere
server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Outputs of the
test

One set of results for each web application deployed on the WebSphere application
server

278

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

279

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Loaded servlets:

Measurement
Unit
Number

Indicates the number of
servlets that were loaded
since
the
last
measurement period.
Reload count:

Number

Indicates the number of
servlets that were reloaded
since the last
measurement period.
Request count:

Number

Indicates the number of
requests that a servlet/JSP
processed since the last
measurement period.
Concurrent requests:

Number

Indicates the current
number of requests
processed concurrently.
Error count:

Number

Indicates the number of
errors in JSP/Servlet since
the last measurement
period.

281

Interpretation

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Service time:

S e r v e r s

Secs

Indicates the response
time of the JSP/servlet.

3.2.5.2

WAS Gateway Test

The WASGateway test reports the number of synchronous and asynchronous requests received by and
responses sent by the WebSphere server.

Purpose

Reports the number of synchronous and asynchronous requests received by and
responses sent by the WebSphere server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Outputs of the
test

One set of results for every Gateway on the WebSphere application server being
monitored

282

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin or

http://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

283

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Sync request count:

Measurement
Unit

Interpretation

Number

Indicates the number of
synchronous requests that
were made, since the last
measurement period.
Sync response count:

Number

Indicates the number of
synchronous responses
that were sent, since the
last measurement period.
Async request count:

Number

Indicates the number of
asynchronous requests
that were made, since the
last measurement period.
Async response count:

Number

Indicates the number of
asynchronous responses
that were made, since the
last measurement period.

3.2.5.3

WAS ORB Performance Test

The WASORBPerformance test reports statistics pertaining to the ORBs (Object Request Broker) on a
WebSphere server.

285

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

Purpose

Reports statistics pertaining to the ORBs (Object Request Broker) on a WebSphere
server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Configurable
parameters for
the test



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

286

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Requests count:

Measurement
Unit

Interpretation

Number

Indicates the number of
requests sent to the ORB,
since
the
last
measurement period.
Concurrent requests
count:

Number

Indicates the current
number of requests
concurrently processed by
the ORB.
Lookup time:

Secs

Indicates the amount of
time taken to lookup an
object reference before
method dispatch can be
carried out.
Processing time:

Secs

Indicates the time that it
takes a registered portable
interceptor to run.

288

An excessively long time may
indicate an EJB container lookup
problem.

M o n i t o r i n g

3.2.5.4

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s

WAS Web Service Test

The WASWebServer test reports statistics pertaining to the web services mounted on a WebSphere
server.

Purpose

Reports statistics pertaining to the web services mounted on a WebSphere server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Outputs of the
test

One set of results for every web service on the WebSphere application server
being monitored

289

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

290

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Loaded services:

Measurement
Unit
Number

Indicates the number of
web services loaded by the
application server since the
last measurement period.
Dispatched requests:

Number

Indicates the number of
requests that were
dispatched by the service
to a target code, since the
last measurement period.
Processed requests:

Number

Indicates the number of
requests dispatched
successfully with
corresponding replies,
since the last
measurement period.
Received requests:

Number

Indicates number of
requests received by the
service.

292

Interpretation

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Response time:

S e r v e r s

Secs

Indicates the average time
between the receipt of a
request and the return of a
reply.
Request response time:

A very high response time could
indicate a bottleneck at the web
service.

Secs

Indicates the average time
between the receipt of the
request and the dispatch
for processing the request.
Reply response time:

Secs

Indicates the average time
between the dispatch of
the reply and return of the
reply.

3.2.5.5

WAS Web Service Test

The WAS JCA Connection Pools test monitors the usage of the JCA connection pools on the WebSphere
Application server.

Purpose

Monitors the usage of the JCA connection pools on the WebSphere Application
server

Target of the test

A WebSphere application server

Agent deploying
the test

An internal agent

Outputs of the
test

One set of results for each connection pool being monitored

293

M o n i t o r i n g

Configurable
parameters for
the test

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



7. SERVERNAME - Provide the name of the server instance being monitored in
the SERVERNAME text box. To know the server name, do the following:



Expand the Servers node in the tree structure in the left pane of the
console, and click on the Application Servers link within.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.

294

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

S e r v e r s



In the right panel, click on the Configuration tab page to view the
configuration of the Deployment Manager. In the Additional Properties section of
the Configuration tab page, expand the Ports node.



A list of ports will then appear. Click on the Details button alongside the
ports list.



Specify this Host name as the SERVERNAME.



Expand the Servers node in the tree structure in the left pane of the
console, and click on Application Servers within.



Doing so invokes the Configuration of the application server instance clicked
on. Scroll down the Configuration tab page to view the Communications
section.



Connect to the WebSphere Administrative console using the URL: http://\admin or

https://\admin.




Expand the System Administration node in the tree-structure in the left pane
of the console and click on the Deployment Manager sub-node within.



M o n i t o r i n g

W e b S p h e r e



A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Connections allocated:

Measurement
Unit

Interpretation

Number

Indicates the number of
connections allocated to
the pool during the last
measurement period.
Connections freed:

Number

Indicates the number of
connections that were
returned to the pool in the
last measurement period.
Connections created:

A very low value of this measure
could result in a shortage of
connections in the pool.

Number

Indicates the number of
connections created during
the last measurement
period.
Connections closed:

Number

Indicates the number of
connections released from
the pool during the last
measurement period.
Connections in pool:

Number

Indicates the number of
connections in this
connection pool.

296

Ideally, this value should be low.

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Free connections in
pool:

S e r v e r s

Number

Indicates the number of
free connection available in
this connection pool.
Waiting threads:

Number

Indicates the number of
threads that are currently
waiting in this connection
pool
Faults:

Faults/sec

Ideally, the value of this measure
should be zero.

Percent

This value of this measure is based
on the number of connections that
are configured for this connection
pool.

Indicates the number of
faults (for e.g., timeouts)
that
occurred
in
this
connection pool per second
during
the
last
measurement period.
Percent of the pool in
use:
Indicates
the
current
utilization
of
this
connection
pool
in
percentage.
Percent of the time that
all connections are in
use:

Percent

Indicates the number of
times
(expressed
as
percentage)
all
the
connections
of
this
connection pool were in
use.
Avg. use time of
connections:

MilliSec

Indicates the average time
for which the connections
of this connection pool
were in use.
Avg. wait time to grand
connection:

MilliSec

Indicates the average time
a client has to wait before
the
connections
were
granted
from
this
connection pool.

297

M o n i t o r i n g

W e b S p h e r e

A p p l i c a t i o n

Managed connections:

S e r v e r s

Number

Indicates the number of
managed connections that
are currently in use in this
connection pool.
Connections associated
with physical
connection:

Number

Indicates the number of
connections
that
are
associated with physical
connections
in
this
connection pool.

298

M o n i t o r i n g

i P l a n e t

A p p l i c a t i o n

S e r v e r s

Chapter

Monitoring iPlanet Application
Servers
The iPlanet Application server is a Java EE application server system, based on the Netscape
Application Server and NetDynamics Application Server.
Figure 4.1 depicts the Netscape Application monitoring model used by an eG agent to monitor iPlanet
application servers. The Operating System, Network, and Tcp layers have already been discussed in the
Monitoring Unix and Windows Servers document. The Application Processes layer tracks the status of
the different processes that comprise the iPlanet application server. Since the iPlanet server requires
the executive server, the C server, and the Java server to be executing in order to function effectively,
the Application Processes layer represents the cumulative state of all of these server processes. Above
the Application Processes layer is the NAS Service layer.

Figure 4.1: Model of an iPlanet Application server showing the different layers monitored for the server
Using the Netscape Application model, administrators can quickly determine the health of the NAS
server engine.
The sections that follow discuss the NAS Service layer only, as all other layers have been discussed
elaborately in the Monitoring Unix and Windows Servers document.

299

M o n i t o r i n g

i P l a n e t

A p p l i c a t i o n

S e r v e r s

4.1 The NAS Service Layer
This layer represents the different services offered by the iPlanet application server. To measure the
state of these services, an eG agent uses the Simple Network Management Protocol (SNMP) support
provided by the iPlanet application server. The details of the NasSnmp test (see Figure 4.2) that
tracks the status of the iPlanet application server are listed below.

Figure 4.2: The NasSnmpTest that maps to the NAS Service layer of an iPlanet application server

4.1.1 NAS SNMP Test
For this test to function properly, the iPlanet application server’s SNMP monitoring capability should be
enabled. Please refer to the iPlanet Administrator Guide to determine how the SNMP capabilities of the
iPlanet application server can be turned on. The outputs of the NasSnmp test are listed below:

Purpose

To measure statistics pertaining to an iPlanet application server

Target of the
test

An iPlanet application server

Agent
deploying the
test

An external agent

300

M o n i t o r i n g

Configurable
parameters for
the test

i P l a n e t

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST –The host for which the test is to be configured.
3. PORT - The port to which the specified HOST listens
4. SNMPPORT – The port number on which the application server is exposing the
SNMP MIB
5. SNMPVERSION – By default, the eG agent supports SNMP version 1. Accordingly,
the default selection in the SNMPVERSION list is v1. However, if a different SNMP
framework is in use in your environment, say SNMP v2 or v3, then select the
corresponding option from this list.
6. SNMPCOMMUNITY – The SNMP community name that the test uses to
communicate with the target server. This parameter is specific to SNMP v1 and
v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter will
not appear.
7. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
8. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
9. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
10. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm

11. ENCRYPTFLAG – This flag appears only when v3 is selected as the
SNMPVERSION. By default, the eG agent does not encrypt SNMP requests.
Accordingly, the ENCRYPTFLAG is set to NO by default. To ensure that SNMP
requests sent by the eG agent are encrypted, select the YES option.
12. ENCRYPTTYPE – If the ENCRYPTFLAG is set to YES, then you will have to
mention the encryption type by selecting an option from the ENCRYPTTYPE list.
SNMP v3 supports the following encryption types:



DES – Data Encryption Standard



AES – Advanced Encryption Standard

13. ENCRYPTPASSWORD – Specify the encryption password here.
14. CONFIRM PASSWORD – Confirm the encryption password by retyping it here.

301

M o n i t o r i n g

i P l a n e t

A p p l i c a t i o n

S e r v e r s

15. DATA OVER TCP – By default, in an IT environment, all data transmission occurs
over UDP. Some environments however, may be specifically configured to
offload a fraction of the data traffic – for instance, certain types of data traffic or
traffic pertaining to specific components – to other protocols like TCP, so as to
prevent UDP overloads. In such environments, you can instruct the eG agent to
conduct the SNMP data traffic related to the equalizer over TCP (and not UDP).
For this, set the DATA OVER TCP flag to Yes. By default, this flag is set to No.

Outputs of the
test
Measurements
made by the
test

One set of results for each iPlanet engine. The iPlanet application server has three
main engines – KXS, KCS, and KJS.

Measurement
Request rate:

Measurement
Unit
Reqs/Sec

A high request rate is an indicator of
server overload. By comparing the request
rates across application servers, an
operator can gauge the effectiveness of
load balancers (if any) that are in use.

Secs

An increase in response time associated
with one of the NAS engines can indicate a
problem with the specific engine alone.

Percent

A value of close to 100% is indicative of a
bottleneck with a specific engine.

KB/Sec

A sudden change in data transmit rate can
be indicative of a change in the
characteristics of key applications hosted
on the engine.

KB/Sec

A sudden increase or decrease in data rate
to the engine is indicative of either an
increase or decrease in popularity of
applications hosted on the NAS engine
under consideration.

Rate of requests to the
NAS engine.

Response time:
Average response time
(in
seconds)
for
requests serviced by
this NAS engine.
Threads utilized:
The
percentage
of
threads of this engine
that are in active use.
Data transmit rate:
Rate at which the data
is transferred by the
engine in response to
the incoming requests.
Data received rate:

Interpretation

Rate at which the data
is received by the
engine.

302

M o n i t o r i n g

C o l d f u s i o n

A p p l i c a t i o n

S e r v e r s

Chapter

Monitoring Coldfusion Application
Servers
ColdFusion is an application server and software development framework used for the development
of computer software in general. This application server is most often used for data-driven web sites
or intranets, and can also be used to generate remote services such as SOAP web services or Flash
remoting. Error-free functioning of the ColdFusion server is therefore a key requirement for the
continuous availability of these critical end-user services. To ensure that the ColdFusion is always
accessible and is performing to peak capacity, it is necessary to constantly watch over the
performance of the server, spot error conditions before they actually occur, and resolve the errors
with immediate effect.
eG Enterprise provides an exclusive ColdFusion monitoring model that facilitates 24x7 monitoring of
the ColdFusion server, and proactive alerting of probable problem conditions with the server. This
model is shown in Figure 5.1.

Figure 5.1: Layer model for a Coldfusion server
Every layer of this hierarchical model is mapped to one/more tests that collectively enable
administrators to determine the following:



Is the ColdFusion server overloaded with requests?



Are the applications hosted on ColdFusion able to obtain quick access to the database?



Is there an unusual increase in the data traffic to and from the server?

303

M o n i t o r i n g

C o l d f u s i o n

A p p l i c a t i o n

S e r v e r s



Is the server processing requests quickly, or is the request queue growing steadily?



Is the server sending out timely responses for the requests, or is the responsiveness of the
server too slow?

The sections to come discuss each of the top 2 layers of Figure 5.1 above. The remaining layers have
been dealt with extensively in the Monitoring Unix and Windows Servers document.

5.1 The CF Service Layer
This layer represents the different services offered by the Coldfusion application server. To monitor
Coldfusion servers, the eG Enterprise suite uses monitoring capabilities supported by the Coldfusion
servers. A special test page installed on the Coldfusion server interfaces with the Coldfusion server’s
monitoring interface to extract a variety of statistics pertaining to the Coldfusion server. The status of
this layer is determined by the results of a Coldfusion test (see Figure 5.2). The details about the
Coldfusion test have been provided in the following sections.

Figure 5.2: The ColdfusionTest that maps to the CF Service layer of a Coldfusion application server

5.1.1 Coldfusion Test
This tests measures statistics pertaining to a Coldfusion server. The outputs of this test are described
below.

Purpose

To measure statistics pertaining to a Coldfusion application server

Target of the
test

A Coldfusion application server

Agent
deploying the
test

An internal agent

304

M o n i t o r i n g

Configurable
parameters for
the test

C o l d f u s i o n

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST – The host for which the test is to be configured.
3. PORT - The port to which the specified host listens
4. WEBSERVERPORT – The port number of a web server that is configured with
the Coldfusion monitoring capability. This web server has to be one that is
already configured to work with a Coldfusion application server

5. SSL - Select Yes if SSL (Secure Socket Layer) has been enabled, and No if it is
not.

Outputs of the
test
Measurements
made by the
test

One set of results for each Coldfusion application server.

Measurement
Request rate:

Measurement
Unit
Reqs/Sec

A high request rate is an indicator of
server overload. By comparing the
request
rates
across
application
servers, an operator can gauge the
effectiveness of load balancers (if any)
that are in use.

Reqs/Sec

An unusually low or high rate of
database accesses from one or more
applications hosted on the Coldfusion
application server may provide hints on
anomalies with the applications.

KB/Sec

A sudden change in data transmit rate
can be indicative of a change in the
characteristics of key applications
hosted on the engine.

KB/Sec

A sudden increase or decrease in data
rate to the application server is
indicative of either an increase or
decrease in popularity of applications
hosted on the Coldfusion application
server.

Number

An increase in requests queued can
indicate a bottleneck at the application
server. The problem may be caused
either because of an application server
problem, a problem with specific
applications hosted on the Coldfusion
server, or because of backend problems
(e.g., with the database server,
payment gateway, etc.).

Rate of requests to the
Coldfusion server.

Database access rate:
Rate of database accesses
issued by applications
executing on the
Coldfusion server.
Data transmit rate:
Rate at which the data is
transferred by the
application server in
response to incoming
requests.
Data receive rate:
Rate at which the data is
received by the application
server.

Requests queued:

Interpretation

Number of requests
queued waiting for service
from the Coldfusion
application server.

305

M o n i t o r i n g

C o l d f u s i o n

A p p l i c a t i o n

Requests running:

S e r v e r s

Number

An increase in requests running may
indicate an increase in user workload
(to be sure, correlate this value with
the data transmit and receive rates).
Alternatively, a slowdown at the
application server may also cause the
requests
that
are
simultaneously
executing to increase.

Reqs/Sec

An increase in the time out rate of
requests is a clear indication of a
problem with one or more applications
executing on a Coldfusion server.
Requests may time out because of an
application problem, because of failure
to access external servers (e.g.,
databases, payment gateways), or
because
of
server
overload.
By
determining whether all of the web
transactions that use the Coldfusion
server are experiencing problems, an
operator can determine if the problem
is related to the application server or
with specific applications.

Secs

An increase in queuing delay reflects a
server bottleneck.

Secs

An increase in response time can occur
because
there
are
too
many
simultaneous requests or because of a
bottleneck with any of the applications
executing on the server.

Secs

A large value of DB access time can be
caused by poor query construction,
bottlenecks at the database server(s),
etc.

Number of requests
currently being processed
by the application server.

Requests timeout rate:
Rate at which requests are
timing out while waiting
for service from the
Coldfusion server.

Avg queue time:
Average time in seconds
spent by a request waiting
for service by the
Coldfusion server.
Avg response time:
Average time (in seconds)
for processing a request at
the server.
Avg database access
time:
Average time (in seconds)
for database accesses from
applications executing on
the Coldfusion server.

5.1.2 Coldfusion Log Test
This test monitors a ColdFusion log file for warnings. This test is disabled by default. To enable the
test, go to the ENABLE / DISABLE TESTS page using the menu sequence : Agents -> Tests ->
Enable/Disable, pick Coldfusion as the Component type, Performance as the Test type, choose this test
from the DISABLED TESTS list, and click on the >> button to move the test to the ENABLED TESTS list.
Finally, click the Update button.

Purpose

To monitor a ColdFusion log file for warnings

306

M o n i t o r i n g

C o l d f u s i o n

A p p l i c a t i o n

S e r v e r s

Target of the
test

A ColdFusion server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST –The host for which the test is to be configured.
3. PORT - The port to which the specified HOST listens
4. LOGFILE – The path to the ColdFusion log file to be monitored
5. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for every ColdFusion server

Measurement
Warnings:

Measurement
Unit
Number

The number of warnings
reported
by
the
ColdFusion
server
during
the
last
measurement period.

Interpretation
The detailed diagnosis for this metric
provides more details on the warnings
reported in the Coldfusion logs.
Information about the URLs that are
providing slow response, the number of
slow responses, and the average response
time for these accesses can also be
received.

5.2 The CF DB Access Layer
This layer tracks the statistics of the database access of the applications hosted on a Coldfusion server
with the help of the Coldfusion test (see Figure 5.3).

307

M o n i t o r i n g

C o l d f u s i o n

A p p l i c a t i o n

S e r v e r s

Figure 5.3: The ColdfusionTest that maps to the CF DB Access layer of a Coldfusion application server

308

M o n i t o r i n g

S i l v e r S t r e a m

A p p l i c a t i o n

S e r v e r s

Chapter

Monitoring SilverStream Application
Servers
The SilverStream Application Server is a comprehensive, J2EE certified platform for building and
deploying enterprise-class Web applications. It supports the full Java 2 Enterprise Edition standard -JavaServer Pages (JSP pages), Enterprise JavaBeans (EJBs), and all the other J2EE 1.2 components
and technologies.
Errors in the functioning of this application server could have an adverse impact on the overall
performance and availability of the dependent web applications; this in turn would result in
significantly decreasing the productivity of the end-users, who transact business with the help of these
web applications. To avoid such an unpleasant outcome, the SilverStream application server’s
performance should be scrutinized regularly.
eG Enterprise provides a special SilverStream monitoring model (see Figure 6.1) to periodically
monitor the helath of the Silverstream application server. The eG agents can track the availability,
performance, and usage of SilverStream application servers. Critical information about the health of a
SilverStream server such as the current load on the server, current sessions, percentage of thread
pool utilization, processing time for requests, memory usage patterns, etc., can be obtained from the
eG agents. Coupled with eG Enterprise's relative thresholding, single click diagnosis, historical
trending, and integrated monitoring capabilities, this new enhancement offers a powerful, single stop
monitoring solution for customers using SilverStream application servers.
The SilverStream server uses a SilverServer application process to start the server. The Processes test
parameters for SilverStream servers should be configured to monitor this process. To obtain statistics
specific to a SilverStream server, the eG Enterprise suite relies on the Client API provided by
SilverStream server. SilverStream server can be configured to listen on three different ports –
Runtime port, design port and Admin port. When the SilverStream server is first installed on a
particular port number, all the three port numbers will have the same value. Through eG Enterprise's
administrative interface, the Admin port number on which the SilverStream server listens must be
specified. For the eG Enterprise suite to use the SilverStream Client API, the root path of the
SilverStream installation must be specified through eG Enterprise's administrative interface. If
SilverStream server is configured to authenticate users connecting to it, a valid username and
password must be specified through eG Enterprise's administrative interface. While configuring the
parameters for this test, the value corresponding to the ISAUTHENTICATED should be “Y”.

309

M o n i t o r i n g

S i l v e r S t r e a m

A p p l i c a t i o n

S e r v e r s

Figure 6.1: Layer model for a SilverStream application server
The sections that follow elaborate on the first layer of Figure 6.1 only, as all other layers have been
extensively dealt with in the Monitoring Unix and Windows Servers document.

6.1 The Silver Stream Service Layer
This layer tracks the health of the SilverStream server using the SilverStream test (see Figure 6.2).

Figure 6.2: Tests mapping to the Silver Stream Service layer

6.1.1 SilverStream Test
Using the SilverStream client API, this test tracks various statistics relating to the SilverStream server.

Purpose

To measure the statistics pertaining to a SilverStream application server

Target of the test

A SilverStream application server

Agent deploying
the test

An internal agent

310

M o n i t o r i n g

Configurable
parameters for
the test

S i l v e r S t r e a m

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. ADMIN PORT – The port number on which the SilverStream server is listening
for administrative purpose

3. ROOTPATH – Root path where SilverStream server is installed.
4. ISAUTHENTICATED – Is the server running in an authenticated mode or not.
Value should be entered as Y (for Yes) and N (for No).

5. USER - If the SilverStream server is running in an authenticated mode, then
the user name has to be supplied.

6. PASSWORD - If the SilverStream server is running in an authenticated mode,
then the password corresponding to the user name has to be supplied.

7. CONFIRM PASSWORD – Confirm the PASSWORD by retyping it here.
Outputs of the
test
Measurements
made by the test

One set of results for each SilverStream application server.

Measurement
Server usage:

Measurement
Unit
Number

If the server is under high utilization
for a prolonged period of time, it is
indicative of the server reaching its
maximum capacity.

Percent

If this measure reaches 100%, then
the client connections are queued
before execution. In this situation,
the total number of threads spawned
by the server can be increased
depending on the capacity.

Percent

This measure is indicative of the
percent of threads waiting for further
user requests.

Reqs/Sec

A sudden increase in this value
indicates an unusual burst of
requests for your application server.
This usually means that there is
sudden
high
activity
on
your
application or abnormal/malicious
attacks.

The current utilization of
the server. It is a value
between 1 and 4. A value
of 1 indicates light
utilization while a value of
4 indicates high utilization
of the server.
Thread usage:
The percentage of threads
associated with the client
connections. This includes
threads, which may or may
not be currently handling
user requests.
Percent idle threads:
The percentage of threads
associated with client
connections, which are not
currently handling user
requests.
Request rate:

Interpretation

Number of requests per
second to the SilverStream
server.

311

M o n i t o r i n g

S i l v e r S t r e a m

A p p l i c a t i o n

Mean response time:

S e r v e r s

Secs

A sudden increase in the mean
response time is indicative of a
bottleneck on the application server.

Secs

A sudden increase in the maximum
response time is indicative of a
bottleneck on the application server.

KB/Sec

A large increase in the data
transmission rate can be indicative of
an increase in the popularity of one
or more web sites hosted on the
server. This measure is directly
related to Request_rate.

Percent

A sudden increase in memory
utilization may be indicative of
memory leaks in the applications
running on the server. When this
measure reaches 100%, it indicates
that the SilverStream server has
reached its maximum capacity.

Number

This is indicative of the number of
user sessions maintained in the
server.

Number

This measure is indicative of the
number of user sessions waiting for
further user requests.

The average time taken to
process the requests
coming to the server.
Max response time:
The maximum time taken
to process any request
since the start of the
server.
Data transmit rate:
The rate of data
transmitted by the server
while serving client
requests.
Memory utilization:
The percentage of memory
used by the SilverStream
server inside the Java
virtual machine in which it
is running.
Total sessions:
The total number of
sessions associated with
the server.
Idle sessions:
The number of sessions
associated with the server,
which is in idle state.

312

M o n i t o r i n g

J R u n

A p p l i c a t i o n

S e r v e r s

Chapter

Monitoring JRun Application
Servers
JRun is an application server from Macromedia that is based on Sun Microsystems' Java 2 Platform,
Enterprise Edition (J2EE). JRun consists of Java Server Page (JSP), Java servlets, Enterprise
JavaBeans, the Java Transaction Service (JTS), and the Java Messaging Service (JMS). JRun works
with the most popular Web servers including Apache, Microsoft's Internet Information Server (IIS),
and any other Web server that supports Internet Server Application Program Interface (ISAPI) or the
Web's common gateway interface (CGI).
If the JRun application server is unable to process the business logic swiftly and efficiently, end-users
are bound to experience a significant slowdown in the responsiveness of the web application they
interact with. To ensure that the applications supported by the JRun server function optimally at all
times, constant monitoring of the JRun server’s availability and internal operations is essential.
eG Enterprise presents a hierarchical JRun monitoring model (see Figure 7.1), which executes
diagnostic tests on the JRun server to extract a wide variety of performance heuristics. Using these
statistics, administrators can guage the following:



Does the JRun server have adequate threads for handling its current and anticipated
workload? Are too many requests waiting for threads?



Is the server able to process requests quickly?



Are there any requests for which processing has been delayed significantly?



Have any requests been dropped by the server?



Are too many requests awaiting processing?



How quickly does the server respond to a request?



Has sufficient memory been allocated to the server to serve requests effectively?



Is the user activity on the server unusually high?

313

M o n i t o r i n g

J R u n

A p p l i c a t i o n

S e r v e r s

Figure 7.1: Layer model for a JRun application server
The sections to come will discuss the JVM and JRUN Service layers only, as the other layers have been
discussed elaborately in the Monitoring Unix and Windows Servers document.

7.1 The JVM Layer
This layer collectively reports the resource usage and overall health of the JRun JVM.

Figure 7.2: The tests mapped to the JVM layer
All the tests listed in Figure 7.2 have been discussed in the previous chapters.

7.2 The JRUN Service Layer
This layer tracks the health of the JRun service. The status of the JRUN Service layer is determined by
the results of three tests, namely: JRunThread test, JRunService test and JRunServer test.

314

M o n i t o r i n g

J R u n

A p p l i c a t i o n

S e r v e r s

Figure 7.3: Tests mapping to the JRUN Service layer

7.2.1 JRun Threads Test
The JRun server includes a thread pool, wherein each thread in the pool is used to service an incoming
request. The size of the thread pool is dynamically increased / decreased depending on the rate of
incoming requests. Since a single JRun server may comprise of multiple instances, the JrunThread test
monitors the thread pool usage for each of the server instances. One set of results is reported per
instance of a JRun server. In Figure 7.3, there are two instances of the JRun server. Hence, two sets
of results are reported corresponding to the default, App1 instances.

Purpose

To measure the thread pool usage of all the server instances of a JRun server

Target of the test

An Allaire JRun Server

Agent deploying
the test

An internal agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured.
3. PORT - The port number on which the host is listening
4. HOMEDIR - The directory in which the JRun server has been installed
In Windows environments, if the JRun server is installed at d:\program
files\allaire\jrun, HomeDir has to be set to d:\progra~1\allaire\jrun.

Measurements
made by the test

Measurement

Measurement
Unit

315

Interpretation

M o n i t o r i n g

J R u n

A p p l i c a t i o n

S e r v e r s

Thread utilization:

Percent

This
indicates
the
percentage
of
existing
threads,
which
are
currently active.

A value consistently close to 100% is
indicative of a bottleneck in the JRun
server. In this case, incoming requests
may have to wait for threads to be
available to process the requests and the
user may see an increased delay while
accessing the server.
To improve the performance of a JRun
server 3.0, consider increasing the
jcp.endpoint.main.active.threads
property
in
the
local.properties
configuration
file
(residing
in
the
JRUN_HOME_DIR>/servers/servername),
so that the server can allocate more
threads for processing user requests.
In case of a JRun server 4.0 modify the
activeHandlerThreads attribute of the
WebService in the jrun.xml file located
in
the
/servers//SERVER-INF directory.
If the value of this metric is below 20%,
the thread pool size may be set to be too
large. Hence, consider reducing the
jcp.endpoint.main.active.threads
property in local.properties file of the
JRun server 3.0.
In case of a JRun server 4.0, modify the
activeHandlerThreads attribute of the
WebService in the jrun.xml file located
in
the
/servers//SERVER-INF directory.

316

M o n i t o r i n g

J R u n

A p p l i c a t i o n

S e r v e r s

Waiting threads:

Number

This indicates the number
threads that are being
queued in the server.

A high value indicates that several
threads are getting queued since the
server is busy processing other threads.
To reduce this number for a JRun server
3.0, you should increase the value of the
jcp.endpoint.main.active.threads
property
in
the
local.properties
configuration file, so that the server's
JVM
can
handle
more
threads
simultaneously. At the same time, care
must be taken to ensure that the server
does not become less efficient.
In case of a JRun server 4.0, modify the
activeHandlerThreads attribute of the
WebService in the jrun.xml file located
in
the
/servers//SERVER-INF directory.

Total threads:

Number

This metric indicates the
overall number of threads
in all states in the server.

This metric must be considered in
conjunction with the Thread utilization
metric. Where possible ensure that the
number of total threads is not set to be
much larger than the maximum number
of simultaneous requests expected for
the server.

Note:
If a new server instance is added to a JRun application server while its being monitored, it will take
at least an hour for the new instance to appear in the eG monitor console.

7.2.2 JRun Service Test
This test monitors the processing of requests by a JRun server.

Purpose

To measure metrics related to the performance of all the server instances of a JRun
server

Target of the test

An Allaire JRun Server

Agent deploying
the test

An internal agent

Configurable
parameters for
the test

317

M o n i t o r i n g

Measurements
made by the test

J R u n

A p p l i c a t i o n

S e r v e r s

Measurement
Avg queue time:

Measurement
Unit
Secs

This value indicates the
average time a request
spends
waiting
for
processing by the server.

Interpretation
A low value here would indicate that
the server is performing optimally. An
increase in queuing delay reflects a
server bottleneck. For a JRun server
3.0,
consider
increasing
the
jcp.endpoint.main.active.threads
property in the local.properties
file, to ensure that additional threads
are available to process incoming
requests.
In case of a JRun server 4.0, modify
the activeHandlerThreads attribute
of the WebService in the jrun.xml file
located
in
the
/servers//SERVER-INF directory.
A number of compute intensive tasks
can also end up increasing the
queuing time for a request.

Avg processing time:

Secs

A high value here would indicate that
processing time per request is very
high, as the requests might be
performing complex/time-consuming
computation. Consider determining
which of the server side processing
tasks is compute intensive and
explore ways of minimizing the server
processing overhead.

Secs

An increase in response time can
occur because there are too many
simultaneous requests or because of a
bottleneck with any of the applications
executing on the server.

KB/Sec

An unusually high value indicates an
increase in workload to the server.
The Avg queue time metric indicates
whether the increased incoming data
rate
is
impacting
the
server
performance.

KB/Sec

An unusually high value indicates an
increase in workload to the server.
The Avg queue time metric indicates
whether the increased incoming data
rate
is
impacting
the
server
performance.

This value indicates the
average time taken by the
server to process a request.

Avg response time:
This indicates the average
time spent by a request in
queuing and processing.
Data read rate:
This indicates the total rate
of data received by the
server for all incoming
requests.
Data write rate:
This indicates the total rate
of data sent by the server in
response to all incoming
requests.

318

M o n i t o r i n g

J R u n

A p p l i c a t i o n

S e r v e r s

Delayed requests:

Number

While the Avg queue time gives an
indicator of how long requests are
being queued, this measure provides
an indicator of how many requests
were queued at the server over the
last measurement period. This value
should be close to 0 for peak
performance.

Number

This value should be close to 0 at
most times. Therefore, if a JRun
server 3.0 drops a large number of
requests, consider increasing the
parameter
jcp.endpoint.main.max.threads, in
the local.properties file. This
parameter indicates the maximum
number of requests that can be
processed or queued at any instant.

This value
indicates the
number of requests delayed
at the server.

Dropped requests:
This indicates the number of
requests that were dropped
since the server could not
process them or queue
them.

In case of a JRun server 4.0, modify
the activeHandlerThreads attribute
of the WebService in the jrun.xml file
located
in
the
/servers//SERVER-INF directory.
Request rate:

Reqs/sec

This indicates the rate of
requests handled by the
JRun server.

This value is an indicator of server
workload across all its connectors.

Note:
If a new server instance is added to a JRun application server while its being monitored, it will take
at least hour for the new instance to appear in the eG monitor console.

7.2.3 JRun Server Test
This test periodically tracks the measures related to the Java virtual machine of all the instances of a
JRun server.

Purpose

To measure the metrics related to the Java virtual machine (JVM) of all the
instances of a JRun server

Target of the test

An Allaire JRun Server

Agent deploying
the test

An internal agent

319

M o n i t o r i n g

Configurable
parameters for
the test

J R u n

A p p l i c a t i o n

S e r v e r s

Measurements
made by the test

Measurement
Total server memory:

Measurement
Unit
MB

An unusually large usage of memory
by the server is a cause for concern.
Further analysis is required to
determine whether any of the
applications running have memory
leaks. If the memory is still low,
consider starting the server with a
higher memory usage setting.

A very low value of free memory is
also an indication of high memory
utilization within the JVM.

Number

A high value of this measure may
indicate an increase in the server
workload.

Number

A high value may indicate that there
are a large number of sessions
residing in the memory. Some of
these sessions might be active or
inactive. If the value is too high,
consider changing the value of
session.persistence to false. This
would stop persistence of a session
when the server is terminated.

This value indicates the
total amount of memory
that is being currently used
by the server.

Free server memory:
This value indicates the
total amount of memory
that is not in use by the
server.
Active sessions:
This indicates the current
number of active sessions in
the server.
Sessions in memory:

Interpretation

This indicates the number of
active sessions in the server
memory. Sessions can be
persisted
to
a
session
repository depending upon
your JRun configuration.

Note:
If a new server instance is added to a JRun application server while its being monitored, it will take
at least hour for the new instance to appear in the eG monitor console.

320

M o n i t o r i n g

O r i o n

S e r v e r s

Chapter

Monitoring Orion Servers
An Orion Server is a J2EE-compliant application server that is used in many Internet environments.
Since a minute or marked deterioration in the performance of this application server can adversely
impact the health of the web-based application it supports, it is imperative that the Orion server is
monitored continuously, and probable problems detected quickly and accurately.
eG Enterprise has designed a specialized Orion monitoring model (see Figure 8.1), that not only
monitors the Orion server top-down, but also detects problems with the server before they occur,
automatically triages the problems and assigns priorities to each, and alerts administrators
accordingly.

Figure 8.1: Layer model of an Orion/Tomcat server
The following section deals with the top layer alone, as the other layers have already been discussed
at length in the Monitoring Unix and Windows Servers document.

8.1 The Java Application Server Layer
The tests depicted by Figure 8.2 execute on this layer, and report on the thread and memory usage of
the Orion server.

321

M o n i t o r i n g

O r i o n

S e r v e r s

Figure 8.2: Tests associated with the Java Application Server layer

8.1.1 Java Server Web Access Test
This test reports the performance statistics pertaining to the Java Virtual Machine (JVM) running on an
Orion server.

Purpose

Reports the performance statistics pertaining to the Java Virtual Machine (JVM)
running on an Orion server.

Target of the
test

An Orion server

Agent
deploying
test

An Internal agent

the

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST – The host on which the Orion/Tomcat server is running
3. PORT – The port on which the specified Orion/Tomcat server is listening for
HTTP requests
4. EGURI - The JavaServerTest makes use of a file named EgPerfTest.jsp to generate
measures. By default, this file is located in the /lib
directory. To execute the JavaServerTest, move this file to one of the
application directories of the Orion server. On Unix, you can execute the script
/opt/egurkha/bin/setup_jserver to do this. While configuring the JavaServerTest,
specify the location of the application directory where the EgPerfTest.jsp file
resides,
in
the
EGURI
text
box,
in
the
following
format:
http://. For example, assume that
the EgPerfTest.jsp is available in the JavaTest directory of the host
192.168.10.57:7077. Therefore, EGURI would be: http://192.168.10.57:7077/JavaTest.

Outputs of the
test
Measurements
made by the
test

One set of results for the server being monitored

Measurement
Active threads:

Measurement
Unit
Number

Indicates the number of
active threads in the
JVM.

322

Interpretation
A high value for this measure
indicative of a high load on the JVM.

M o n i t o r i n g

O r i o n

S e r v e r s

Total memory usage:

A high value indicates a high processing
capability of the JVM. Watch for
increasing memory usage over time,
which could indicate a memory leak in
one or more applications hosted on the
application server.

A very low value of free memory is an
indication of high memory utilization on
the JVM.

Indicates
the
total
memory available in the
JVM.

Free memory:
Indicates the unused
memory in the JVM.

323

M o n i t o r i n g

T o m c a t

S e r v e r s

Chapter

Monitoring Tomcat Servers
The Tomcat server is a Java based Web Application container that was created to run Servlets and
JavaServer Pages (JSP) in Web applications. As part of Apache's open source Jakarta project, it has
nearly become the industry accepted standard reference implementation for both the Servlets and JSP
API.
Application developers capitalize on the capabilities of the Tomcat container to build robust web
applications that provide mission-critical services to end users. Naturally, the 24 x 7 availability and
speedy responsiveness of the Tomcat server is imperative for the applications and the dependent
businesses to remain afloat.

Note:
The eG agents are capable of monitoring Tomcat version 3.x, 4.x, 5.x, and 6.0, in an agent-based
and an agentless manner.

Using the specialized monitoring model that eG Enterprise offers for the Tomcat server (see Figure
9.1), one can extensively monitor every layer of the Tomcat server, automatically correlate
performance across the layers, and accurately locate the problem source.

Figure 9.1: The layer model of the Tomcat server
Each layer depicted by Figure 9.1 performs a number of tests on the Tomcat server and evaluates the
critical aspects of Tomcat performance such as thread usage, memory management, processing
capabilities of the servlets, efficiency of the JSP engine, etc. To enable the monitoring, you will first
324

M o n i t o r i n g

T o m c a t

S e r v e r s

have to install a custom egtomcat application (i.e., the egtomcat.war file in the \lib
directory) on the server. Next, if you are monitoring Tomcat 6.0, then, after war deployment, copy the
commons-logging-api.jar file in the \lib directory to the \lib directory.
On the other hand, if you are monitoring Tomcat 5.x, then copy the commons-logging-api.jar file in the
\bin directory to the \lib directory.
Note:
The eG agent can monitor a Tomcat server, only if the Tomcat server executes on JDK 1.5 or
above.

The eG agent can then begin monitoring the Tomcat Server. The statistics so collected enable
administrators find quick and accurate answers to persistent performance-related queries, such as the
following:
Availability monitoring

 Is the Tomcat server available?
 How quickly does it respond to requests?
 Have adequate threads been allocated to the

Thread pool usage monitoring

pool?

 Are too many threads idle?
Servlet monitoring

Jasper monitoring

 Is the server taking too long to process servlets?
Which servlet is contributing to the delay?

 How frequently do reloads occur?
 Are the JSPs been updated often?
 How quickly are connectors processing requests?

Connector monitoring

Is there a delay in request processing? If so,
which connector is responsible for the delay?

 How much traffic is generated by a connector?
 Have

any
processing?

errors

occurred

during

request

 Has the JVM been up and running continuously?
 How many classes have been loaded/unloaded by
JVM monitoring

the JVM?

 Is there a garbage collection bottleneck?
 Does the JVM have sufficient free memory?
 Is the server workload high? How many sessions
Session manager monitoring

are currently active on the server?

 Were too many sessions rejected?
Cache monitoring

 Are cache hits optimal?
 Are disk accesses low?

The sections to come discuss the top 3 layers of the layer model, as the remaining layers have already
been discussed in the Monitoring Unix and Windows Servers document.

325

M o n i t o r i n g

T o m c a t

S e r v e r s

9.1 The JVM Layer
The tests associated with this layer provide users with valuable insight into the various aspects of Java
Virtual Machines including:



Class loading/unloading



Server availability



Garbage collection activity



Memory/CPU management

Figure 9.2: Tests associated with JVM layer

9.1.1 JMX Connection to JVM
This test reports the availability of the target Java application, and also indicates whether JMX is
enabled on the application or not. In addition, the test promptly alerts you to slowdowns experienced
by the application, and also reveals whether the application was recently restarted or not.

Purpose

Target of the
test

A Tomcat server

Agent
deploying the
test

An internal/remote agent

326

M o n i t o r i n g

Configurable
parameters for
the test

T o m c a t

S e r v e r s

Outputs of the
test
Measurements
made by the
test

One set of results for the Java application being monitored

Measurement
Unit

Measurement
JMX availability:

Percent

Indicates whether the target
application is available or not
and whether JMX is enabled or
not on the application.

JMX response time:

Secs

Indicates the time taken to
connect to the JMX agent of the
Java application.
Has the PID changed?

Interpretation
If the value of this measure is
100%, it indicates that the Java
application is available with JMX
enabled. The value 0 on the other
hand, could indicate one/both the
following:



The
Java
application is unavailable;



The
Java
application is available,
but JMX is not enabled;

A high value could indicate a
connection bottleneck.

Indicates whether/not the
process ID that corresponds to
the Java application has
changed.

327

M o n i t o r i n g

T o m c a t

S e r v e r s

9.1.2 JVM File Descriptors Test
This test reports useful statistics pertaining to file descriptors.

Purpose

Reports useful statistics pertaining to file descriptors

Target of the
test

A Tomcat server

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

One set of results for the Java application being monitored

Measurement
Unit

Measurement
Open file descriptors in JVM:

Number

Indicates the number of file
descriptors currently open for
the application.
Maximum file descriptors in
JVM:

Number

Indicates the maximum number
of file descriptors allowed for the
application.
File descriptor usage by JVM:

Percent

Indicates the file descriptor
usage in percentage.

328

Interpretation

M o n i t o r i n g

T o m c a t

S e r v e r s

9.1.3 Java Classes Test
This test reports the number of classes loaded/unloaded from the memory.

Purpose

Reports the number of classes loaded/unloaded from the memory

Target of the
test

A Tomcat server

Agent
deploying the
test

An internal/remote agent

329

M o n i t o r i n g

Configurable
parameters for
the test

T o m c a t

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter only if the MODE is set to JMX. Here,
specify the port at which the JMX listens for requests from remote hosts. Ensure
that
you
specify
the
same
port
that
you
configured
in
the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

330

M o n i t o r i n g

T o m c a t

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

Outputs of the
test
Measurements
made by the
test

One set of results for the Java application being monitored

Measurement
Unit

Measurement
Classes loaded:

Number

Indicates the number of classes
currently loaded into memory.

331

Interpretation
Classes are fundamental to the
design of Java programming
language.
Typically,
Java

M o n i t o r i n g

T o m c a t

S e r v e r s

Classes unloaded:

Number

Indicates the number of classes
currently
unloaded
from
memory.

Total classes loaded:

Number

Indicates the total number of
classes loaded into memory
since the JVM started, including
those subsequently unloaded.

9.1.4 JVM Garbage Collections Test
Manual memory management is time consuming, and error prone. Most programs still contain leaks.
This is all doubly true with programs using exception-handling and/or threads. Garbage collection (GC)
is a part of a Java application’s JVM that automatically determines what memory a program is no
longer using, and recycles it for other use. It is also known as "automatic storage (or memory)
reclamation''. The JVM Garbage Collections test reports the performance statistics pertaining to the
JVM's garbage collection.

Purpose

Reports the performance statistics pertaining to the JVM's garbage collection

Target of the
test

A Tomcat server

Agent
deploying the
test

An internal/remote agent

332

M o n i t o r i n g

Configurable
parameters for
the test

T o m c a t

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

333

M o n i t o r i n g

T o m c a t

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

Outputs of the
test
Measurements
made by the

One set of results for the Java application being monitored

Measurement

Measurement
Unit

334

Interpretation

M o n i t o r i n g

test

T o m c a t

S e r v e r s

No of garbage collections
started:

Number

Indicates the number of times
garbage collection started to
release
dead
objects
form
memory
during
the
last
measurement period.
Time taken for garbage
collection:

Secs

Indicates the time taken to
perform the current garbage
collection operation.
Percent of time spent by JVM
for garbage collection:

Percent

Indicates the percentage of time
spent by JVM in garbage
collection
during
the
last
measurement period.

9.1.4.1.1

JVM Memory Pool Garbage Collections Test

Purpose

Helps assess the impact of the garbage collection activity on the availability and
usage of memory in each memory pool of the JVM

Target of the
test

A Tomcat Server

Agent
deploying the
test

An internal/remote agent

335

M o n i t o r i n g

Configurable
parameters for
the test

T o m c a t

S e r v e r s



By contacting the Java runtime (JRE) of the application via JMX



Using GC logs

Outputs of the
test
Measurements
made by the
test

One set of results for every GarbageCollector:MemoryPool pair on the JVM of the
server being monitored

Measurement
Unit

Measurement
Has garbage collection
happened?:
Indicates
whether
collection
occurred
memory
pool
in
measurement period.

garbage
on
this
the
last

336

Interpretation
This measure reports the value
Yes if garbage collection took
place or No if it did not take place
on the memory pool.
The
numeric
values
that
correspond to the measure values
of Yes and No are listed below:

M o n i t o r i n g

T o m c a t

S e r v e r s

State

Value

Yes

Number

Indicates the number of time in
the last measurement pool
garbage collection was started
on this memory pool.
Initial memory before GC:

Indicates the initial amount of
memory (in MB) that this
memory pool requests from the
operating system for memory
management
during
startup,
before GC process.
Initial memory after GC:

Indicates the initial amount of
memory (in MB) that this
memory pool requests from the
operating system for memory
management
during
startup,
after GC process

337

M o n i t o r i n g

T o m c a t

S e r v e r s

Max memory before GC:

Indicates the maximum amount
of memory that can be used for
memory management by this
memory pool, before GC
process.
Max memory after GC:

Indicates the maximum amount
of memory (in MB) that can be
used for memory management
by this pool, after the GC
process.

Committed memory before
GC:

Indicates the amount of memory
that
is
guaranteed
to
be
available for use by this memory
pool, before the GC process.
Committed memory after GC:

Indicates the amount of memory
that
is
guaranteed
to
be
available for use by this memory
pool, after the GC process.
Used memory before GC:

Indicates the amount of memory
used by this memory pool before
GC.
Used memory after GC:

Indicates the amount of memory
used by this memory pool after
GC.

338

Comparing the value of these two
measures for a memory pool will
provide you with insights into the
effectiveness of the garbage
collection activity.
If garbage collection reclaims a
large amount of memory from the
memory pool, then the Used
memory after GC may drop lower
than the Used memory before
GC. On the other hand, if the
garbage
collector
does
not
reclaim much memory from a
memory pool, or if the Java
application
suddenly
runs
a
memory-intensive process when
GC is being performed, then the
Used memory after GC value may
exceed the Used memory before
GC.

M o n i t o r i n g

T o m c a t

S e r v e r s

Percentage memory
collected:

Percent

Mins

Indicates the percentage of
memory collected from this pool
by the GC activity.

Collection duration:
Indicates the time taken by this
garbage collector for collecting
unused memory from this pool.

9.1.5 JVM Threads Test
This test reports the status of threads running in the JVM. Details of this test can be used to identify
resource-hungry threads.

Purpose

Reports the status of threads running in the JVM

Target of the
test

A Tomcat server

Agent
deploying the
test

An internal/remote agent

339

M o n i t o r i n g

Configurable
parameters for
the test

T o m c a t

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

340

M o n i t o r i n g

T o m c a t

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

17. ENCRYPTPASSWORD – Specify the encryption password here.
18. CONFIRM PASSWORD – Confirm the encryption password by retyping it here.
19. TIMEOUT - This parameter appears only if the MODE is set to SNMP. Here, specify
the duration (in seconds) within which the SNMP query executed by this test
should time out in the TIMEOUT text box. The default is 10 seconds.
20. DD FREQUENCY - Refers to the frequency with which detailed
diagnosis measures are to be generated for this test. The default is 1:1. This
indicates that, by default, detailed measures will be generated every time this
test runs, and also every time the test detects a problem. You can modify this
frequency, if you so desire. Also, if you intend to disable the detailed diagnosis
capability for this test, you can do so by specifying none against DD
FREQUENCY.

341

M o n i t o r i n g

T o m c a t

S e r v e r s

21. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:



The eG manager license should allow the detailed diagnosis capability

 Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

Outputs of the
test
Measurements
made by the
test

One set of results for the Java application being monitored

Measurement
Unit

Measurement
Total threads:

Interpretation

Number

Indicates the total number of
threads (including daemon and
non-daemon threads).
Runnable threads:

Number

The detailed diagnosis of this
measure, if enabled, provides the
name of the threads, the CPU
usage by the threads, the time
for which the thread was in a
blocked state, waiting state, etc.

Number

If a thread is trying to take a lock
(to enter a synchronized block),
but the lock is already held by
another thread, then such a
thread is called a blocked thread.

Indicates the current number of
threads in a runnable state.

Blocked threads:
Indicates the number of threads
that are currently in a blocked
state.

The detailed diagnosis of this
measure, if enabled, provides indepth information related to the
blocked threads.

342

M o n i t o r i n g

T o m c a t

S e r v e r s

Waiting threads:

Number

Indicates the number of threads
that are currently in a waiting
state.

Timed waiting threads:

Number

Indicates the number of threads
in a TIMED_WAITING state.

343

M o n i t o r i n g

T o m c a t

S e r v e r s

Low CPU threads:

Number

Indicates the number of threads
that are currently consuming
CPU lower than the value
configured in the PCT LOW CPU
UTIL THREADS text box.
Medium CPU threads:

Number

Peak threads:

Ideally, the value of this measure
should be very low. A high value
is indicative of a resource
contention at the JVM. Under
such circumstances, you might
want to identify the resourcehungry threads. To know which
threads are consuming excessive
CPU, use the detailed diagnosis of
this measure.

Number

Indicates the highest number of
live threads since JVM started.
Started threads:

Number

Indicates the the total number of
threads
started
(including
daemon,
non-daemon,
and
terminated) since JVM started.
Daemon threads:

Number

Indicates the current number of
live daemon threads.
Deadlock threads:

Number

Indicates the current number of
deadlocked threads.

344

M o n i t o r i n g

T o m c a t

S e r v e r s



Go to the \jre\lib\management folder used by the target application, and edit the
management.properties file in that folder.



Append the following line to the file:
com.sun.management.enableThreadContentionMonitoring



Finally, save the file.

9.1.6 JVM Cpu Usage Test
This test measures the CPU utilization of the JVM. If the JVM experiences abnormal CPU usage levels,
you can use this test to instantly drill down to the threads that are contributing to the CPU spike.
Detailed stack trace information provides insights to code level information that can highlight
problems with the design of the Java application.

Note:


If you want to collect metrics for this test from the JRE MIB – i.e, if the MODE parameter of
this test is set to SNMP – then ensure that the SNMP and SNMP Trap services are up and
running on the application host.



While monitoring a Java application executing on a Windows 2003 server using SNMP,
ensure that the community string to be used during SNMP access is explicitly added when
starting the SNMP service.

Purpose

Measures the CPU utilization of the JVM

Target of the
test

A Tomcat server

Agent
deploying the
test

An internal/remote agent

345

M o n i t o r i n g

Configurable
parameters for
the test

T o m c a t

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
7. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

346

M o n i t o r i n g

T o m c a t

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

347

M o n i t o r i n g

T o m c a t

S e r v e r s

20. DD FREQUENCY - Refers to the frequency with which detailed
diagnosis measures are to be generated for this test. The default is 1:1. This
indicates that, by default, detailed measures will be generated every time this
test runs, and also every time the test detects a problem. You can modify this
frequency, if you so desire. Also, if you intend to disable the detailed diagnosis
capability for this test, you can do so by specifying none against DD
FREQUENCY.
21. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for the Java application being monitored

Measurement
Unit

Measurement
CPU utilization of JVM:

Percent

Indicates the percentage of total
available CPU time taken up by
the JVM.

Interpretation
If
a
system
has
multiple
processors, this value is the total
CPU time used by the JVM divided
by the number of processors on
the system.
Ideally, this value should be low.
An unusually high value or a
consistent increase in this value is
indicative of abnormal CPU usage,
and
could
warrant
further
investigation.
In such a situation, you can use
the detailed diagnosis of this
measure, if enabled, to determine
which
runnable
threads
are
currently utilizing excessive CPU.

The detailed diagnosis of the CPU utilization of JVM measure lists all the CPU-consuming threads
currently executing in the JVM, in the descending order of the Percentage Cpu Time of the threads; this
way, you can quickly and accurately identify CPU-intensive threads in the JVM. In addition to CPU
usage information, the detailed diagnosis also reveals the following information for every thread:



The number of times the thread was blocked during the last measurement period, the total
duration of the blocks, and the percentage of time for which the thread was blocked;

348

M o n i t o r i n g

T o m c a t

S e r v e r s



The number of times the thread was in wating during the last measurement period, the total
duration waited, and the percentage of time for which the thread waited;



The Stacktrace of the thread, using which you can nail the exact line of code causing the CPU
consumption of the thread to soar;

Figure 9. 3: The detailed diagnosis of the CPU utilization of JVM measure

9.1.7 JVM Memory Usage Test
This test monitors every memory type on the JVM and reports how efficiently the JVM utilizes the
memory resources of each type.

Note:


This test works only on Windows platforms.



This test can provide detailed diagnosis information for only those monitored Java
applications that use JRE 1.6 or higher.

Purpose

Monitors every memory type on the JVM and reports how efficiently the JVM utilizes
the memory resources of each type

Target of the
test

A Tomcat server

Agent
deploying the
test

An internal/remote agent

349

M o n i t o r i n g

Configurable
parameters for
the test

T o m c a t

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

350

M o n i t o r i n g

T o m c a t

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

17. ENCRYPTPASSWORD – Specify the encryption password here.
18. CONFIRM PASSWORD – Confirm the encryption password by retyping it here.
19. TIMEOUT - This parameter appears only if the MODE is set to SNMP. Here, specify
the duration (in seconds) within which the SNMP query executed by this test
should time out in the TIMEOUT text box. The default is 10 seconds.
20. HEAP ANALYSIS – By default, this flag is set to off. This implies that the test will
not provide detailed diagnosis information for memory usage, by default. To
trigger the collection of detailed measures, set this flag to On.
21. JAVA HOME – This parameter appears only when the HEAP ANALYSIS flag is
switched On. Here, provide the full path to the install directory of JDK 1.6 or higher
on the application host. For example, c:\JDK1.6.0.

351

M o n i t o r i n g

T o m c a t

S e r v e r s

22. DD FREQUENCY - Refers to the frequency with which detailed
diagnosis measures are to be generated for this test. The default is 1:1. This
indicates that, by default, detailed measures will be generated every time this
test runs, and also every time the test detects a problem. You can modify this
frequency, if you so desire. Also, if you intend to disable the detailed diagnosis
capability for this test, you can do so by specifying none against DD
FREQUENCY.
23. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:



The eG manager license should allow the detailed diagnosis capability

 Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

Outputs of the
test
Measurements
made by the
test

One set of results for every memory type on the JVM being monitored

Measurement
Unit

Measurement
Initial memory:

Interpretation

Indicates the amount of memory
initially allocated at startup.
Used memory:

Indicates the amount of memory
currently used.

It includes the memory occupied
by all objects, including both
reachable
and
unreachable
objects.
Ideally, the value of this measure
should be low. A high value or a
consistent increase in the value
could indicate gradual erosion of
memory resources. In such a
situation, you can take the help of
the detailed diagnosis of this
measure (if enabled), to figure
out which class is using up
memory excessively.

352

M o n i t o r i n g

T o m c a t

S e r v e r s

Available memory:

This is the difference between
Available memory and Used
memory.

Indicates the amount of memory
guaranteed to be available for
use by the JVM.

Free memory:
Indicates the amount of memory
currently available for use by the
JVM.
Max free memory:

Ideally, the value of this measure
should be high.
MB

Indicates the maximum amount
of memory allocated for the JVM.
Used percentage:

Percent

Indicates the percentage of used
memory.

Ideally, the value of this measure
should be low. A very high value
of this measure could indicate
excessive memory consumption
by the JVM, which in turn, could
warrant further investigation. In
such a situation, you can take the
help of the detailed diagnosis of
this measure (if enabled), to
figure out which class is using up
memory excessively.

The detailed diagnosis of the Used memory measure, if enabled, lists all the classes that are using the
pool memory, the amount and percentage of memory used by each class, the number of instances of
each class that is currently operational, and also the percentage of currently running instances of each
class. Since this list is by default sorted in the descending order of the percentage memory usage, the
first class in the list will obviously be the leading memory consumer.

353

M o n i t o r i n g

T o m c a t

S e r v e r s

Figure 9. 4: The detailed diagnosis of the Used memory measure

9.1.8 JVM Uptime Test
This test tracks the uptime of a JVM. Using information provided by this test, administrators can
determine whetherthe JVM was restarted. Comparing uptime across Java applications, an admin can
determine the JVMs that have been running without any restarts for the longest time.

Purpose

Tracks the uptime of a JVM

Target of the
test

A Tomcat server

Agent
deploying the
test

An internal/remote agent

354

M o n i t o r i n g

Configurable
parameters for
the test

T o m c a t

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

355

M o n i t o r i n g

T o m c a t

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

356

M o n i t o r i n g

T o m c a t

S e r v e r s

Outputs of the
test
Measurements
made by the
test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the
detailed diagnosis measures should not be 0.

One set of results for every Java application monitored

Measurement
Unit

Measurement
Has JVM been restarted?:
Indicates whether or not the JVM
has restarted during the last
measurement period.

Interpretation
If the value of this measure is No,
it indicates that the JVM has not
restarted. The value Yes on the
other hand implies that the JVM
has indeed restarted.
The
numeric
values
that
correspond to the restart states
discussed above are listed in the
table below:
State

Value

Yes

Note:
By default, this measure reports
the value Yes or No to indicate
whether a JVM has restarted. The
graph of this measure however,
represents the same using the
numeric equivalents – 0 or 1.

357

M o n i t o r i n g

T o m c a t

S e r v e r s

Uptime during the last
measure period:

Secs

Administrators may wish to be
alerted if a JVM has been running
without a reboot for a very long
period. Setting a threshold for
this metric allows administrators
to determine such conditions.

Indicates the time period that
the JVM has been up since the
last time this test ran.

Total uptime of the JVM:
Indicates the total time that the
JVM has been up since its last
reboot.

9.1.9 Tests Disabled by Default for a Tomcat Server
The tests discussed above are enabled by default for a Tomcat server. In addition to these tests, the
eG agent can be optionally configured to execute a few other tests that report critical statistics related
to CPU usage, thread usage, and the uptime of the Tomcat JVM. To enable one/more of these tests,
open the AGENTS – TESTS CONFIGURATION page using the Agents -> Tests -> Configure menu sequence,
select Tomcat from the Component type list, scroll down the test list that appears to view the DISABLED
TESTS section, select the check box corresponding to the JVM test of interest to you, and then, click the
Update button. These tests have been discussed below.

9.1.9.1

Java Transactions Test

When a user initiates a transaction to a Java-based web application, the transaction typically travels
via many Java components before completing execution and sending out a response to the user.
The key Java components have been briefly described below:



M o n i t o r i n g

T o m c a t

S e r v e r s



A look at the methods that took too long to execute, thus leading you to those methods that
may have contributed to the slowdown;



Single-click access to each invocation of a chosen method, which provides pointers to when
and where a method spent longer than desired;



A quick glance at SQL queries and Java errors that may have impacted the responsiveness of
the transaction;



eg_jtm.jar



aspectjrt.jar



aspectjweaver.jar



jtmConn.props



jtmLogging.props



jtmOther.props

2. Login to the system hosting the Java application to be monitored.

359

M o n i t o r i n g

T o m c a t

S e r v e r s

3. If the eG agent will be 'remotely monitoring' the target Java application (i.e., if the Java
application is to be monitored in an 'agentless manner'), then, copy all the files mentioned above
from the \lib directory (on Windows; on Unix, this will be /opt/egurkha/lib) of the eG
agent to any location on the Java application host.
4. Then, proceed to edit the start-up script of the Java application being monitored, and append the
following lines to it:
set JTM_HOME=<>
"-javaagent:%JTM_HOME%\aspectjweaver.jar"
"-DEG_JTM_HOME=%JTM_HOME%"

Note that the above lines will change based on the operating system and the web/web application server being
monitored.
Then, add the eg_jtm.jar, aspectjrt.jar, and aspectjweaver.jar files to the CLASSPATH of the Java
application being monitored.
Finally, save the file. Once this is done, then, the next time the Java application starts, the eG JTM
Monitor scans the web requests to the application for configured URL patterns. When a match is
found, the eG JTM Monitor collects the desired metrics and stores them in memory.
Then, every time the eG agent runs the Java Transactions test, the agent will poll the eG JTM Monitor
(on the target application) for the required metrics, extract the same from the application's
memory, and report them to the eG manager.
5. Next, edit the jtmConn.props file. You will find the following lines in the file:
#Contains the connection properties of eGurkha Java Transaction Monitor
JTM_Port=13631
Designated_Agent=
By default, the JTM_Port parameter is set to 13631. If the Java application being monitored listens
on a different JTM port, then specify the same here. In this case, when managing a Java Application
using the eG administrative interface, specify the JTM_Port that you set in the jtmConn.props file as
the Port of the Java application.
Also, against the Designated_Agent parameter, specify the IP address of the eG agent which will poll
the eG JTM Monitor for metrics. If no IP address is provided here, then the eG JTM Monitor will treat
the host from which the very first 'measure request' comes in as the Designated_Agent.

6. Finally, save the jtmConn.props file.
Then, proceed to configure the Java Transactions test as discussed in Section 9.1.9.1 of this document.

360

M o n i t o r i n g

9.1.9.2

T o m c a t

S e r v e r s

JVM Details Test

This reveals the health of the Tomcat class loaders and daemon threads, and also indicates JVM
availability.

Purpose

Reveals the health of the Tomcat class loaders and daemon threads, and also
indicates JVM availability

Target of the test

Tomcat server

Agent deploying the
test

An internal agent

361

M o n i t o r i n g

T o m c a t

Configurable
parameters for the
test

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT – The port number on which the Tomcat server listens
4. MEASUREMENT MODE – This test can extract metrics from Tomcat using
either of the following mechanisms:



By deploying the egtomcat.war file in the \lib directory of
the eG agent host on the Tomcat server;



By contacting the Java runtime (JRE) of Tomcat via JMX

To configure the test to use egtomcat.war file, first, select the War File option.
Then, refer to the Configuring and Monitoring Application Servers document
to know how to deploy the WAR file on the target Tomcat server.
On the other hand, if you want the test to use JMX instead, then first, select
the JMX option. Then, follow the procedure detailed in the Configuring and
Monitoring Application Servers document to configure the test to use JMX. By
default, the JMX option is chosen here.
5. JNDINAME – This parameter appears only if the MEASUREMENT MODE is set
to JMX. The JNDINAME is a lookup name for connecting to the JMX connector.
By default, this is jmxrmi. If you have registered the JMX connector in the
RMI registry using a different lookup name, then you can change this
default value to reflect the same.
6. JMX REMOTE PORT – This parameter appears only if the MEASUREMENT
MODE is set to JMX. Here, specify the port at which the JMX listens for
requests from remote hosts. Ensure that you specify the same port that you
configured in the catalina.sh (or catalina.bat file) file in the
/bin folder of the target Tomcat server (refer to the
Configuring and Monitoring Application Servers document for more details).
7. JMX USER, JMX PASSWORD, and CONFIRM PASSWORD – These parameters
appear only if the MEASUREMENT MODE is set to JMX. If JMX requires
authentication only (but no security), then ensure that the JMX USER and JMX
PASSWORD parameters are configured with the credentials of a user with
read-write access to JMX. To know how to create this user, refer to the
Configuring and Monitoring Application Servers document. Confirm the
password by retyping it in the CONFIRM PASSWORD text box.
8. SSL - This parameter appears only if the MEASUREMENT MODE is set to War
File. Indicate YES if the Tomcat server is SSL-enabled.
9. URL - This parameter appears only if the MEASUREMENT MODE is set to War
File. Specify the URL of the managed Tomcat server to enable the test to
connect to it and extract measures from it. The URL specification should be
of the format: http://{TomcatIP}:{TomcatPort}.
10. USERNAME, PASSWORD, and CONFIRM PASSWORD – These parameters
appear only if the MEASUREMENT MODE is set to War File. In the USERNAME
text box, specify a name of a user who has been assigned the Manager role on
the Tomcat server to be monitored; these users are typically allowed to
control web applications deployed on the Tomcat server. Specify the
PASSWORD of this user, and confirm the password by retyping it in the
CONFIRM PASSWORD text box.

362

M o n i t o r i n g

T o m c a t

S e r v e r s

11. ENCRYPTPASS - This parameter appears only if the MEASUREMENT MODE is
set to War File. Select Yes if you want to encrypt the password.

Outputs of the test
Measurements
made by the test

One set of results for the Tomcat server being monitored.

Measurem
ent Unit

Measurement
Total classes loaded:

Interpretation

Number

Refers to the total number of
classes that have been loaded
since the Java virtual machine
started execution.
Classes loaded:

Number

Indicates the number of
classes that have been loaded
in the Java virtual machine
since the last measurement
period.
Classes unloaded:

Number

Indicates the total number of
classes
that
have
been
unloaded in the Java virtual
machine
since
the
last
measurement period.

Total daemon threads:

Number

Indicates the current number
of live daemon threads.
Live threads:

Number

Indicates the current number
of live daemon and nondaemon threads.

363

Classes are fundamental to the
design
of
Java
programming
language.
Like
many
server
applications, Tomcat installs a
variety of class loaders (that is,
classes
that
implement
java.lang.ClassLoader)
to
allow
different portions of the container,
and the web applications running
on the container, to have access to
different repositories of available
classes and resources. A consistent
decrease in the number of classes
loaded and unloaded could indicate
a
road-block
in
the
loading/unloading of classes by the
class loader. If left unchecked,
critical resources/classes could be
rendered
inaccessible
to
web
applications,
thereby
severely
affecting application performance.
The main function of the daemon
threads is to provide service to
other threads, running in the same
process as the daemon thread. If
the value of this measure is equal
to
that
of
the
Live_threads
measure, then JVM would stop
executing; in other words, when the
only remaining threads are the
daemon threads, then JVM shuts
down and so does Tomcat.

M o n i t o r i n g

T o m c a t

S e r v e r s

Deadlock threads:
The
current
number
deadlock threads

Ideally, the value of this measure
should be 0. A non-zero value
indicates the occurrence of a
deadlock. When a thread attempts
to acquire a resource that is already
locked by another thread, a
deadlock situation arises.

Mins

To ensure that the JVM is up and
running for a long time, you need
to make sure that at least one nondaemon thread is executing at all
times. This is because, without any
non-daemon threads, the daemon
threads have no recipients for the
service it provides; it hence brings
down both the JVM and Tomcat.

Server uptime:
The uptime of Java virtual
machine

9.1.9.3

Number

Tomcat JVM Garbage Collection Test

Manual memory management is time consuming, and error prone. Most programs still contain leaks.
This is all doubly true with programs using exception-handling and/or threads. Garbage collection (GC)
is a part of Tomcat's JVM that automatically determines what memory a program is no longer using,
and recycles it for other use. It is also known as "automatic storage (or memory) reclamation''. The
JVMGarbage test reports the performance statistics pertaining to the JVM's garbage collection.

Purpose

Reveals how well the Tomcat's JVM performs garbage collection

Target of the test

A Tomcat server

Agent deploying the
test

An internal agent

364

M o n i t o r i n g

T o m c a t

Configurable
parameters for the
test

S e r v e r s



By deploying the egtomcat.war file in the \lib directory of
the eG agent host on the Tomcat server;



By contacting the Java runtime (JRE) of Tomcat via JMX

365

M o n i t o r i n g

T o m c a t

S e r v e r s

11. ENCRYPTPASS - This parameter appears only if the MEASUREMENT MODE is
set to War File. Select Yes if you want to encrypt the password.

Outputs of the test
Measurements
made by the test

One set of results for the Tomcat server being monitored.

Measurem
ent Unit

Measurement
No of collections :

Number

If adequate memory is not allotted
to the JVM, then the value of this
measure would be very high. A high
value of this measure is indicative
of a high frequency of GC. This is
not a good sign, as GC, during its
execution, has the tendency of
reducing
the
performance
for
applications, and a high frequency
of GC would only adversely impact
the application's performance. To
avoid this, it is recommended that
you allot sufficient memory to the
JVM.

Secs

A shorter GC execution time is
desired
to
avoid
issues
in
application
performance
and
database connection bottlenecks.

Percent

By
carefully
examining
the
application behavior in terms of
memory utilization, you should
arrive at an optimal ratio of the
number of times the GC needs to
run and how long it should take to
complete. Accordingly, you can
fine-tune the GC activity.

Indicates the number of
garbage collections that were
performed by the JVM since
the last measurement period.

Time taken :
Indicates the time taken for
GC execution, since the last
measurement period.
Elapsed time :
Indicates the percentage of
time spent on GC execution.

9.1.9.4

Interpretation

JVM Memory Test

The memory system of the Java Virtual machines manages two types of memory, which are Heap and
Non Heap. To define Heap, the Java virtual machine is a heap that is the runtime data area from
which memory for all class instances and arrays are allocated. It is created at the Java Virtual Machine
start-up and the memory for the objects is reclaimed by an automatic memory management systems
known as Garbage collector. The Heap may be of fixed size or may be expanded and shrunk.
The Java virtual machine has a method area that is shared among all threads. This method area is
called non heap. It stores per class structures such as runtime constant pool field and method data,
and the code for methods and constructors. It is created at the Java Virtual Machine start up.
In order to ensure the uninterrupted functioning of the Tomcat server, sufficient memory resources
need to be made available to the JVM memory pools. Inadequacies in memory allocations could lead
to slow start up issues or intermittent application failures. The JVMMemoryTest periodically reports
usage statistics of the JVM memory pools, so that memory bottlenecks are promptly detected and
resolved.
366

M o n i t o r i n g

T o m c a t

S e r v e r s

Purpose

To indicate the memory of individual memory pools of the Java virtual machine

Target of the test

A Tomcat server

Agent deploying the
test

An internal agent

367

M o n i t o r i n g

T o m c a t

`Configurable
parameters for the
test

S e r v e r s



By deploying the egtomcat.war file in the \lib directory of
the eG agent host on the Tomcat server;



By contacting the Java runtime (JRE) of Tomcat via JMX

368

M o n i t o r i n g

T o m c a t

S e r v e r s

11. ENCRYPTPASS - This parameter appears only if the MEASUREMENT MODE is
set to War File. Select Yes if you want to encrypt the password.

Outputs of the test

One set of results for the Tomcat server being monitored.

Measurements
made by the test

Measurem
ent Unit

Measurement
Used:
Indicates the amount
memory currently in use.

Interpretation

MB
of

Free:

Ideally, this value should be high.
An unusually low value for the
available memory can indicate a
memory bottleneck. Check the
memory utilization of individual
processes
to
figure
out
the
process(es)
that
has
(have)
maximum memory consumption
and look to tune their memory
usages and allocations accordingly.

An unusually high usage of memory
by the Java Virtual machine from
the OS is a cause of concern.
Further analysis is required to
determine if specific applications or
queries are consuming excess
memory.

Indicates the amount of
unused memory currently
available in a server.

Initial :
Indicates the initial amount of
memory that Java virtual
machine requests from the
operating system (OS) for
memory management during
startup.

369

M o n i t o r i n g

T o m c a t

S e r v e r s

Pending objects:

Number

Indicates the number of
objects in the heap/non-heap
memory for which finalization
is pending.

Finalization allows an object to
gracefully clean up after itself when
it is being collected. When the
garbage collector detects that an
object is garbage, the garbage
collector calls the object's Finalize
method (if it exists) and then the
object's memory is reclaimed - in
other words, the garbage collector
frees the memory allocated to the
object.
This measure is available only for
the
Heap_Memory
and
Nonheap_Memory descriptors of this
test. A high value for this measure
indicates that a chunk of heap /
non-heap memory (as the case
may be) in the JVM is awaiting
reclamation.
Object
finalization
facilitates efficient memory re-use,
and thus ensures that the JVM
memory pools do not run out of
memory. If the value of this
measure grows continuously, it
could imply that objects are not
releasing the memory resources
properly. This in turn could be
because the Finalize method does
not exist for some objects, or there
could be a bottleneck in the
invocation of the method. Either
way, thorough investigation can
only provide pointers to the source
of the problem.

9.2 The Web Server Layer
Using the tests associated with the Web Server layer, administrators can:



Quickly identify availability issues with the web server component of Tomcat



Effectively monitor the Tomcat cache and thread pools, and determine whether allocations are
in accordance with current and expected usage

370

M o n i t o r i n g

T o m c a t

S e r v e r s

Figure 9.5: Tests associated with Web Server layer
The Http test associated with this layer emulates a user accessing the web server component of
Tomcat, and reports its availability and responsiveness. Since this test has been discussed elaborately
in the Monitoring Web Servers document, the sections to come will deal with the TomcatCache test
and TomcatThreads test only.

9.2.1 Tomcat Cache Test
A well-sized cache could go a long way in reducing direct disk accesses and the resultant processing
overheads. The TomcatCache test reveals whether/not the Tomcat server cache is effectively utilized.

Purpose

Reveals whether/not the Tomcat server cache is effectively utilized.

Target of the test

A Tomcat server

Agent deploying the
test

An internal agent

371

M o n i t o r i n g

T o m c a t

Configurable
parameters for the
test

S e r v e r s



By deploying the egtomcat.war file in the \lib directory of
the eG agent host on the Tomcat server;



By contacting the Java runtime (JRE) of Tomcat via JMX

372

M o n i t o r i n g

T o m c a t

S e r v e r s

11. ENCRYPTPASS - This parameter appears only if the MEASUREMENT MODE is
set to War File. Select Yes if you want to encrypt the password.

Outputs of the test
Measurements
made by the test

One set of results for Tomcat server being monitored.

Measurem
ent Unit

Measurement
Access count:

Interpretation

Number

The
number
of
cache
accesses
since
the
last
measurement period.
Hits count:

Number

Physical I/O takes a significant
amount of time, and also increases
the CPU resources required. The
server
configuration
should
therefore ensure that the required
information is available on the
memory. A low value of this
measure indicates that physical I/O
is greater.

A high value ensures higher cache
hits and lower physical I/O.

Indicates the number of
requests served from the
cache
since
the
last
measurement period.

Cache size:
Indicates the current size of
cache.

9.2.2 TomcatThreads Test
The Http connector in the Tomcat Web server represents a Connector component that supports the
HTTP/1.1 protocol, which enables Catalina to function as a stand-alone web server, besides its ability
to execute servlets and JSP pages. A particular instance of this component listens for connections on a
specific TCP port number on the server to perform request processing and response creation. You can
have one or more such Connectors configured to form a part of a single Service with each forwarding
service to the associated Engine.
As soon as your server startup time is up, this Connector will create a number of request processing
threads which are based on the value configured for the minSpareThreads attribute. Each incoming
request requires a thread for the duration of that request. If more simultaneous requests are received
than can be handled by the currently available request processing threads, additional threads will be
created up to the configured maximum (the value of the maxThreads attribute). If still more
simultaneous requests are received, they are stacked up inside the server socket created by the
Connector, up to the configured maximum (the value of the acceptCount attribute). Any further
simultaneous requests will receive "connection refused" errors, until resources are available to process
them.
Continuous monitoring of thread pools is imperative to ensure the smooth transaction of business on
the Tomcat web server. The TomcatThreads test periodically observes thread pool usage to proactively
determine inadequacies in the allocation of threads to the pool, and to predict future thread
requirements.

Purpose

Periodically observes thread pool usage to proactively determine inadequacies in
the allocation of threads to the pool, and to predict future thread requirements
373

M o n i t o r i n g

T o m c a t

S e r v e r s

Target of the test

A Tomcat server

Agent deploying the
test

An internal agent

374

M o n i t o r i n g

T o m c a t

Configurable
parameters for the
test

S e r v e r s



By deploying the egtomcat.war file in the \lib directory of
the eG agent host on the Tomcat server;



By contacting the Java runtime (JRE) of Tomcat via JMX

375

M o n i t o r i n g

T o m c a t

S e r v e r s

11. ENCRYPTPASS - This parameter appears only if the MEASUREMENT MODE is
set to War File. Select Yes if you want to encrypt the password.

Outputs of the test
Measurements
made by the test

One set of results for each thread pool managed by the Tomcat server being
monitored.

Measurem
ent Unit

Measurement
Thread count:

Interpretation

Number

Indicates the number of
threads that are currently
assigned to a connector.
Threads busy:

Number

A high value for this measure
indicates that there is hectic activity
at the connector level.

Number

In
the
Tomcat
server,
a
maxThreads attribute can be set for
every connector to indicate the
maximum number of simultaneous
requests that can be handled by
that
connector.
This
measure
reports this maxThreads value. The
default maxThreads value for a
connector is 200.

Indicates the number of
threads which are currently
busy in processing requests.
Max threads:
Indicates
the
maximum
number of threads that this
pool can contain.

If the value of the Thread count
measure grows close to the value of
this measure, it indicates that the
number of threads in the pool
needs to be increased for effective
operation
of
this
application.
Alternatively,
you
may
also
consider changing the maximum
number of threads that a pool can
contain. However, exercise caution
when altering the maximum thread
count, as a very high thread count
can cause the app to slowdown
from excessive memory usage.
Likewise, if the maximum thread
count is set too low, it will cause
requests to block or timeout.
Max spare threads:

Number

Indicates
the
maximum
number of spare threads that
can exist in a thread pool.

376

Ideally for a connector, the default
value is set to 50, which will
determine the maximum number of
unused request processing threads
that will be allowed to exist until
the thread pool starts stopping the
unnecessary threads.

M o n i t o r i n g

T o m c a t

S e r v e r s

Min spare threads :

Number

Indicates
the
minimum
number of spare threads that
are currently available for
processing requests.

Generally, for a connector, the
default value for this parameter is
set to 4, which is less than the
value set in maxThreads. This
attribute will determine the number
of request processing threads that
will be created when this Connector
is first started. The connector will
also make sure it has the specified
number of idle processing threads
available.

9.3 The Java Application Server Layer
The tests associated with this layer report useful statistics related to the performance of critical
Tomcat components such as:



The Manager element



The Tomcat connector



The Tomcat JSP engine



The servlets deployed on Tomcat

Figure 9.6: Tests associated with Java Application Server layer

377

M o n i t o r i n g

T o m c a t

S e r v e r s

The JavaServer test that monitors the memory management capability of the Tomcat JVM has been
discussed in the Monitoring Orion Servers chapter of this document. Therefore, the sections to come
will shed light on the other tests only.

9.3.1 Tomcat Applications Test
The Manager element on the Tomcat server represents the session manager that will be used to
create and maintain HTTP sessions as requested by the associated web application. A session state is
maintained for a period, typically starting with user interactions and ending with last interaction.
Besides memory management, manager also looks into various aspects including CPU usage, network
load that large sessions introduce. The scalability and performance of any web based application
depends upon how well HTTP sessions are transmitted and managed over network.
An application must guarantee that a user's session state is properly maintained in order to exhibit
correct behavior for that user. The TomcatApplications test closely monitors the state of sessions to
every application on the Tomcat server.

Purpose

Closely monitors the state of sessions to every application on the Tomcat server

Target of the test

A Tomcat server

Agent deploying the
test

An internal agent

378

M o n i t o r i n g

T o m c a t

Configurable
parameters for the
test

S e r v e r s



By deploying the egtomcat.war file in the \lib directory of
the eG agent host on the Tomcat server;



By contacting the Java runtime (JRE) of Tomcat via JMX

379

M o n i t o r i n g

T o m c a t

S e r v e r s

11. ENCRYPTPASS - This parameter appears only if the MEASUREMENT MODE is
set to War File. Select Yes if you want to encrypt the password.

Outputs of the test
Measurements
made by the test

One set of results for every application on the Tomcat server being monitored.

Measurem
ent Unit

Measurement
Active sessions:

Number

Indicates the sessions that
are currently active.
Max sessions:

Interpretation
A high value for this measure is
indicative of heavy load on the
Tomcat server.

Number

Indicates
the
maximum
number of active sessions
that can be allowed at one
time on the Tomcat server.
Expired sessions:

Number

A large number of expired sessions
could hint at the need to reset the
TIMEOUT period for sessions on the
Tomcat server.

Number

It is imperative to check if there is
any loss of session state happening
due
to
network
congestion.
Therefore, if the value of this
measure is unusually high, the
reasons
behind
the
unusual
occurrence would have to be
investigated. You can also consider
increasing the maximum active
session count.

Indicates the number of
sessions that expired since
the last measurement period.
Rejected sessions:
Indicates the number of
sessions that were rejected
since the last measurement
period.

9.3.2 Tomcat Connectors Test
The Http connector in the Tomcat Web server, represents a Connector component that supports the
HTTP/1.1 protocol, which enables Catalina to function as a stand-alone web server, besides its ability
to execute servlets and JSP pages. A particular instance of this component listens for connections on a
specific TCP port number on the server to perform request processing and response creation. You can
have one or more such Connectors configured to form a part of a single Service with each forwarding
service to the associated engine.
The TomcatConnectorTest observes the data traffic on each connector and measures the connector's
processing ability.

Purpose

Observes the data traffic on each connector and measures the connector's
processing ability.

Target of the test

Tomcat server

Agent deploying the
test

An internal agent

380

M o n i t o r i n g

T o m c a t

Configurable
parameters for the
test

S e r v e r s



By deploying the egtomcat.war file in the \lib directory of
the eG agent host on the Tomcat server;



By contacting the Java runtime (JRE) of Tomcat via JMX

381

M o n i t o r i n g

T o m c a t

S e r v e r s

11. ENCRYPTPASS - This parameter appears only if the MEASUREMENT MODE is
set to War File. Select Yes if you want to encrypt the password.

Outputs of the test
Measurements
made by the test

One set of results for every connector configured on the Tomcat server being
monitored.

Measurem
ent Unit

Measurement
Request count:

Interpretation

Number

Indicates the number of
requests received by the
connector, since the last
measurement period.
Avg processing time:

Secs

Indicates the average time
taken by the connector to
process requests.
Data sent:

This measure is a clear indicator of
the Connector health. Ideally, this
value should be low. A very high
value
indicates
processing
bottlenecks.

Reports the data that was
sent by the connector since
the last measurement period.
Data received:

Both the Data sent and Data
received
measures
together
indicate the load on the Tomcat
server.

Number

Ideally, the value of this measure
should be 0. A non-zero value
warrants further investigation.

Reports the data that was
received by the connector
since the last measurement
period.
Error count:
Indicates the number of
errors that were reported by
the connector since the last
measurement period.

9.3.3 Tomcat Jsps Test
The TomcatJsps test monitors the performance of the JSPs used by each of the applications deployed
on Tomcat.

Purpose

Monitors the performance of the JSPs used by each of the applications deployed
on Tomcat

Target of the test

A Tomcat server

Agent deploying the
test

An internal agent

382

M o n i t o r i n g

T o m c a t

Configurable
parameters for the
test

S e r v e r s



By deploying the egtomcat.war file in the \lib directory of
the eG agent host on the Tomcat server;



By contacting the Java runtime (JRE) of Tomcat via JMX

383

M o n i t o r i n g

T o m c a t

S e r v e r s

11. ENCRYPTPASS - This parameter appears only if the MEASUREMENT MODE is
set to War File. Select Yes if you want to encrypt the password.

Outputs of the test
Measurements
made by the test

One set of results for every application deployed on the Tomcat server being
monitored.

Measurem
ent Unit

Measurement
Load count:

Interpretation

Number

Indicates the number of JSPs
that have been loaded into
the web application since the
last measurement period.
Reload count:

Number

Indicates the number of JSPs
that have been reloaded since
the last measurement period.

As one of the rules, by default, the
JSP container will automatically
reload the translated class of a JSP
page
whenever
the
page
is
retranslated, a class called by the
page is modified (presuming the
class was loaded by the OC4J JSP
container class loader, not the
system class loader), or any page in
the same application is reloaded.
Using this measure therefore, you
can keep track of the changes
made to the JSP pages.

9.3.4 TomcatServlets Test
A servlet is a small Java program that runs within a web server. These servlets receive and respond to
requests from web clients, usually across HTTP.
Typically, these servlets run inside a servlet container that handles recurring multiple requests. The
performance and reliability of any web based application depends upon how well the requests from
web clients are managed. The TomcatServlets test enables administrators to assess the performance
of servlets on the basis of their request handling capabilities.

Purpose

Assesses the performance of servlets on the basis of their request handling
capabilities

Target of the test

A Tomcat server

Agent deploying the
test

An internal agent

384

M o n i t o r i n g

T o m c a t

Configurable
parameters for the
test

S e r v e r s



By deploying the egtomcat.war file in the \lib directory of
the eG agent host on the Tomcat server;



By contacting the Java runtime (JRE) of Tomcat via JMX

385

M o n i t o r i n g

T o m c a t

S e r v e r s

11. ENCRYPTPASS - This parameter appears only if the MEASUREMENT MODE is
set to War File. Select Yes if you want to encrypt the password.

Outputs of the test
Measurements
made by the test

One set of results for every servlet on the Tomcat server being monitored.

Measurem
ent Unit

Measurement
Request count:

Interpretation

Number

Indicates the number of
requests handled by the
servlet
since
the
last
measurement period.
Avg processing time:

Secs

If the value of this measure
increases consistently, it indicates a
gradual deterioration in the server
performance.

Secs

If the time taken is significantly
high, check for the errors or
bottlenecks that interfere with the
servlet's normal operation.

Secs

Minimum time taken to process the
request is indicative of error free
execution of service by the servlet.

Number

Ideally, the value for this measure
should be 0. An error reported by
this measure is a cause of concern;
an analysis of the underlying
reasons is hence necessitated.

Indicates the average time
taken by the servlet to
process the requests since
the last measurement period.
Max processing time:
Indicates the maximum time
taken by the servlet to
process the requests.
Min processing time:
Indicates the minimum time
taken by the servlet to
process the current request.
Error count:
Indicates
the
errors
encountered by the servlet,
when a request is processed

386

M o n i t o r i n g

S u n O N E

A p p l i c a t i o n

S e r v e r s

Chapter

10
Monitoring SunONE Application
Servers
The Sun ONE Application suite offers a comprehensive list of products for Internet infrastructures, i.e.,
web server, middleware application server, LDAP server, messaging server, and identity server, that
are used in many domains such as banking, trading, healthcare, and logistics to support missioncritical services. IT infrastructures based on the Sun ONE Application suite follow the popular multi-tier
architecture wherein the web server functions as the front-end receiving client requests, the
application server hosts the business logic components, the identity server manages user policies, the
directory server handles access rights and other user information lookups, and the database server
stores and retrieves application data.
Routine monitoring of the infrastructure including the network, system, and application is imperative
to ensure that the infrastructure functions at peak performance at all times. Since each Sun ONE
application performs a different, specialized function, the monitoring has to be specific to each
application – e.g., is the mail server delivering emails? is the application server’s heap effectively
sized?. More importantly, since the different Sun ONE applications inter-operate to support the enduser service, it is critical that the monitoring system track the inter-dependencies between
applications in order to pin-point the exact source of a performance bottleneck in the infrastructure.
The eG Sun ONE monitor offers extensive infrastructure monitoring capabilities for the Sun ONE
application suite. Pre-built models for Sun ONE web, application (see Figure 10.1), directory, and
messaging servers dictate what metrics are to be collected by eG agents, what thresholds are to be
applied to the metrics, and how the metrics are to be correlated in order to assist with problem
diagnosis.

387

M o n i t o r i n g

S u n O N E

A p p l i c a t i o n

S e r v e r s

Figure 10.1: The layer model of a SunONE application server
Using the customized model for the SunONE Application server (see Figure 10.1), you can monitor the
following:



Server up/down time monitoring



Server throughput tracking in terms of requests and data traffic



JDBC connection pool usage levels and connection failure reports



Thread pool execution status levels



Transaction-related measures including the number of transactions that are completed, rolled
back and in-progress



EJB caching efficiency, bean pool-related metrics

10.1 The JVM Layer
This layer collectively reports the resource usage and overall health of the SunONE JVM.

Figure 10.2: The tests mapped to the JVM layer
All the tests displayed in Figure 10.2 have been dealt with in the previous chapters.
388

M o n i t o r i n g

S u n O N E

A p p l i c a t i o n

S e r v e r s

10.2 The SunONE HTTP Layer
To monitor the performance of the virtual web server on the SunONE server, use the SunONE Http
test associated with this layer (see Figure 10.3).

Figure 10.3: Tests associated with the SunONE HTTP layer

10.2.1

SunONE Http Test

This test measures the health of the virtual server configured for the SunONE Http server.

Purpose

Measures the health of the virtual server configured for the SunONE Http server

Target of the test

Any SunONE application server

Agent deploying the
test

An internal agent

Configurable
parameters for the
test

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured.
3. PORT – The port number on which the SunONE application server is running
4. USER – A valid user name for the SunONE server to be monitored
5. PASSWORD – Password for the SunONE server to be monitored
6. ADMIN PORT – The port number on which the “asadmin” tool runs
7. SERVER – Name of the SunONE server to be monitored
8. APPSERVERDIR – The directory in which SunONE application server is
installed

Outputs of the test
Measurements
made by the test

One set of results for every virtual server configured for the web server

Measurem
ent Unit

Measurement
Request rate:

Reqs/Sec

Rate of requests to the web
server
during
the
last
measurement period.

389

Interpretation
This measure reflects the server
workload.

M o n i t o r i n g

S u n O N E

A p p l i c a t i o n

S e r v e r s

Data received:

KB/Sec

Rate at which the data is
received by the server during
the last measurement period
Data transmitted:

KB/Sec

Rate at which the data is
transmitted by the server
during the last measurement
period.
Data
transmit
watermark :

high

The high-water-mark of the
data transmit rate by this
server
Open connections:

Number

Ideally, this measure must be low.
Too many server threads or
processes serving user requests
could
indicate
a
server-side
bottleneck – either with the web
server itself or with one of the
backend components that the web
server uses (e.g., database server).

Number

Changes in the high water mark are
indicative of times when the server
has been a performance bottleneck.
Note that the high water mark
value gets reset every time the
server is restarted.

Number
of
server
threads/processes currently in
use for serving requests

Open
connections
water mark:

high

The high-water-mark of the
open connections count

200 responses :

Percent

Percentage of responses with
a status code in the range of
200-299 during the last
measurement period
300 responses :

Percent

Percentage of responses with
a status code in the range of
300-399 during the last
measurement period
400 errors:

Percent

Percentage of errors with a
status code in the range of
400-499 during the last
measurement period

390

M o n i t o r i n g

S u n O N E

A p p l i c a t i o n

S e r v e r s

500 errors:

Percent

Percentage of errors with a
status code in the range of
500-599 during the last
measurement period
Other responses:

Percent

Percentage of responses with
a status code that is greater
than or equal to 600 during
the last measurement period

10.3 The SunONE DB Layer
The size of the JDBC connection pools governs the constant availability of connections to the
database. The metrics reported by the SunONE DB layer assist you in keeping a close watch on the
fluctuations in the pool size, so that additional connection requirements can be foreseen and allocated
to the pool.

Figure 10.4: Tests associated with the SunONE DB layer

10.3.1

SunONE Jdbc Test

This test reports the performance metrics related to the JDBC connection pools of a SunONE
application server.

Purpose

Reports the performance metrics related to the JDBC connection pools of a
SunONE application server

Target of the test

Any SunONE application server

Agent deploying the
test

An internal agent

391

M o n i t o r i n g

S u n O N E

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

Outputs of the test
Measurements
made by the test

One set of results for every JDBC connection pool

Measurement
Waiting threads:

Measuremen
t Unit
Number

Ideally, this measure should have a
low value. A high value of this
measure indicates that the database
is slow or does not have additional
connections to allocate to service
requests from the web application
server.

Number

This value can increase for various
reasons – connection failures can
happen if the database server is
down or if the maximum limit of
simultaneous connections possible
has been reached. Alternatively, if
the database pool is not adequately
sized (i.e., too few maximum
connections), connection failures can
occur.

Number

The number of threads
that are waiting for a
database connection

Connections failed:
The total number of times
a thread has failed to
acquire a JDBC connection

Connection timeouts:

Interpretation

The
total
number
of
connection requests that
have been timed out

10.4 The SunONE Transactions Layer
The number of transactions that are committed and rolled back by the application server serves as a
good indicator of server workload, processing ability of the server, and potential performance issues (if
any). The test associated with the SunONE Transactions layer (see Figure 10.5) facilitates this
assessment.

392

M o n i t o r i n g

S u n O N E

A p p l i c a t i o n

S e r v e r s

Figure 10.5: Test associated with the SunONE Transactions layer

10.4.1

SunONE Transactions Test

This test reports measures pertaining to the transactions in a SunONE application server.

Purpose

Reports measures pertaining to the transactions in a SunONE application server

Target of the test

Any SunONE application server

Agent deploying the
test

An internal agent

Configurable
parameters for the
test

Outputs of the test
Measurements
made by the test

One set of results for every SunONE application server monitored

Measurement
Transactions completed:

Measurement
Unit
Number

Returns the total number
of transactions that have
been completed by this
server

393

Interpretation

M o n i t o r i n g

S u n O N E

A p p l i c a t i o n

S e r v e r s

Transaction rollbacks:

Number

A high rollback rate indicates a
problem
with
specific
beans.
Possible reasons for this could be
problems with the design and
implementation of the specific bean
or problems with any of the
dependent servers of the bean
(e.g., database server).

Number

A significantly high value may
denote a load on the server. This
may
indicate
that
specific
transactions are taking too long to
process requests.

Returns the total number
of transactions that have
been rolled back by this
server

Transactions in flight:
Returns the total number
of transactions that are
currently in progress

10.5 The SunONE EJB Layer
SunONE application server caches stateless, entity and message driven beans. Adequately sized
caches are essential for quickly servicing client requests. Using the tests associated with this layer
(see Figure 10.6), the caching activity can be closely monitored and deficiencies in size can be
promptly reported.

Figure 10.6: Tests associated with the SunONE EJB layer

10.5.1

SunONE Ejb Cache Test

This test extracts the caching related metrics pertaining to such EJBs. Use the Click here hyperlink in
the test configuration page to configure the EJB groups that need to be monitored by the eG
Enterprise suite. By default, the eG Enterprise system will monitor only those EJBs that are part of a group.

Purpose

Monitor SunONE application server’s EJB caching activity

Target of the test

Any SunONE application server that has one or more stateless, entity, or
message driven beans

Agent deploying the
test

An internal agent

394

M o n i t o r i n g

S u n O N E

Configurable
parameters for the
test

A p p l i c a t i o n

S e r v e r s

9. AUTODISCOVERY – By default, the eG Enterprise suite allows administrators
to configure EJB groups using the eG administrative interface, and reports
metrics pertaining to every group so created. Accordingly, by default,
AUTODISCOVERY is set to NO. If you want EJBs to be discovered and
monitored
automatically,
then
select
the
YES
option
against
AUTODISCOVERY. When this is done, the eG agent automatically discovers
all the EJBs on the SunONE application server, and reports one set of
measures for every EJB hosted on the server.

Outputs of the test
Measurements
made by the test

One set of results for every EJB group configured or EJB (as the case may be)

Measurement
Resize quantity:

Measurement
Unit
Number

The quantity by which the
cache size is reduced when
the number of beans in the
cache
equals
the
maximum cache size (that
is, when cache overflow
occurs)
Cache misses:

This is a configuration parameter
for the EJB cache. This measure will

not be available for Sun Java Application
Server 8.2 and above.

Number

Ideally, the percentage of cache
misses to cache hits should be a
low percentage.

Secs

This is a configuration parameter
for the EJB cache. This measure will

The number of times a
user request did not find a
bean in the cache during
the
last
measurement
period.
Idle timeouts:

Interpretation

Rate at which the cache
cleaner
thread
is
scheduled. This cleaner
thread examines all beans
in
the
cache
and
passivates those beans
that are not accessed for
cache-idle-timeout-inseconds.

not be available for Sun Java Application
Server 8.2 and above.

395

M o n i t o r i n g

S u n O N E

A p p l i c a t i o n

S e r v e r s

Passivations:

Number

Number of passivations.
Applies only to stateful
session beans during the
last measurement period.
Cache hits:

Number

The number of times a
user request found an
entry in the cache during
the
last
measurement
period.
Passivation errors:

Number

Number of errors during
passivation. Applies only to
stateful
session
beans
during
the
last
measurement period.
Beans in cache:

Number

The number of beans in
the cache. This is the
current size of the cache

Expired sessions:

The ratio of beans in cache to the
maximum beans in cache is an
indicator of the cache occupancy.
For maximum performance, the
cache occupancy and hit rate must
be high.

Number

The number of expired
sessions removed by the
cleanup thread during the
last measurement period.
Applies only to stateful
session beans
Max beans in cache:

Number

The maximum number of
beans that can be held in
the cache beyond which
cache overflow occurs
Passivation successes:

This is a configuration parameter
for the EJB cache.

Number

Number
of
times
passivation
completed
successfully. Applies only
to stateful session beans

10.5.2

SunONE EJB Pools Test

This test reports statistics pertaining to the EJB pools for stateful session beans and entity beans. Use
the Click here hyperlink in the test configuration page to configure the EJB groups that need to be

396

M o n i t o r i n g

S u n O N E

A p p l i c a t i o n

S e r v e r s

monitored by the eG Enterprise suite. By default, the eG Enterprise system will monitor only those EJBs that are

part of a group.
Purpose

Monitor SunONE application server’s EJB pools

Target of the test

Any SunONE application server with one or more entity beans or stateful session
beans

Agent deploying the
test

An internal agent

Configurable
parameters for the
test

Outputs of the test
Measurements
made by the test

One set of results for every EJB group configured or every EJB (as thee cae be)

Measurement
Idle timeout:

Measurement
Unit
Sec

Number

Indicates
the
average
number of beans that a
pool contains during the
last measurement period.
Beans destroyed:

This is a configuration setting.

This measure will not be available for
Sun Java Application Server 8.2 and
above.

Returns the time out
period set for the bean.
Steady pool size:

Interpretation

Number

The total number of beans
in a pool that have been
destroyed by the pool
during
the
last
measurement period.

397

This measure will not be available for
Sun Java Application Server 8.2 and
above.

M o n i t o r i n g

S u n O N E

A p p l i c a t i o n

S e r v e r s

Waiting threads:

Number

Returns the number of
threads that are waiting to
get an instance of the
bean
Beans in pool:

The value of this measure should
be low for optimal performance.

Number

The number of beans in
the bean pool currently
Max pool size:

Number

This is a configuration setting.

Number

This is a configuration setting.

The maximum number of
beans that the pool can
contain
Pool resize quantity:

This measure will not be available for
Sun Java Application Server 8.2 and
above.

This is the value by which
the pool size can be
increased or decreased, as
per the requirements.
Beans created:

Number

Indicates the number of
beans that have been
created for a pool, during
the
last
measurement
period

398

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Chapter

11
Monitoring Oracle 9i Application
Servers
Oracle9 i Application Server (Oracle9 i AS) is a J2EE-certified application server, which integrates all
the technology required to develop and deploy e-business portals, transactional applications, and Web
services into a single product. Oracle9 i AS provides a productive development environment for
developers to create Internet Applications including J2EE Applications, Web Services, Enterprise
Portals, Wireless and Business Intelligence Applications. Its open and integration-ready architecture
and standards compliance ensures that Web applications can integrate with any IT environment,
including legacy systems, and Oracle and non-Oracle databases.
This versatility and reliability is what makes the Oracle 9 i AS a key ingredient in advanced IT
infrastructures
providing
critical
services
to
end-users.
Recurring
or
even
sporadic
operational/availability issues with the Oracle 9i AS, can therefore cause prolonged delays in the
delivery of these critical services, in turn causing service level guarantees to be violated!
To avoid the related penalties and loss of reputation, it would be good practice to constantly observe
the functioning of the Oracle 9iAS, and take action as soon as or even before a problem condition
surfaces.
eG Enterprise prescribes an exclusive O9i Application Server monitoring model (see Figure 11.1),
which runs tests on all the key components of the Oracle 9iAS from its JVM, JDBC drivers, caches, to
its web modules, web contexts, transactions, etc. By automatically analyzing the performance data
extracted by these tests from the server, eG Enterprise proactively detects potential bottlenecks to
performance, accurately pin-points the root-cause of these problems, and instantly alerts
administrators to the problem source.

399

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Figure 11.1: The layer model of the Oracle 9i AS
Each layer of the monitoring model depicted by Figure 11.1 monitors and reports metrics on every
performance-influencing aspect of the Oracle 9i AS. Using these metrics, administrators can determine
the following:



Is the Oracle JVM available?



Does the JVM have sufficient free memory?



Is the workload on the JVM optimal?



Is the server able to connect to the database quickly?



Are too many JDBC connections open on the server?



Does the connection cache have adequate free connections?



Is the connection cache utilized effectively?



Are transaction rollbacks kept at a minimum?



Are the web modules processing requests quickly?



Is any web module taking too much time to process requests?



Does the server take too much time to service JSP and servlet requests?

Note:



To effectively monitor an Oracle 9i Application server on Unix, ensure that the install user
of the application server and that of the eG agent (which is monitoring the application
server) are the same.



Any component on an Oracle 9i Application server (be it OC4J or the Oracle HTTP server)
can be monitored by eG only if the Oracle 9i Application Server Release 2.0 is installed,
with dmctl and dmstool.

The sections below discuss the metrics reported by the top 5 layers of Figure 11.1 only, as all other
layers have been dealt with in the Monitoring Unix and Windows Servers document.

400

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

11.1 The Oracle JVM Layer
Use the test associated with this layer to track the workload on and the memory heap usage of the
Oracle JVM.

Figure 11.2: Tests associated with the Oracle JVM layer

11.1.1

Oracle 9i Jvm Test

The JVM test is used to analyze overall JVM performance for the processes of an Oracle 9i AS instance.
The JVM metrics provide useful information about threads and heap memory allocation. You should
check these values to make sure that JVM resources are utilized within expected ranges.

Purpose

Analyzes the overall JVM performance for the processes of an Oracle 9i AS instance

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal Agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT

- In the PORT text box, it is recommended that you provide the port at
which the OPMN (Oracle Process Manager and Notification) process of the Oracle
application server instance listens. To know at which port OPMN listens, click on
the
Ports
tab
in
the
following
URL:
http://:. This tab lists the port
numbers that were assigned to the services executing on the Oracle application
server. The port number displayed against the Oracle notification server
request port entry is the OPMN port, and the same should be specified in the
PORT text box.

4. HOMEDIR – The absolute path of the directory in which the Oracle 9i application
server has been installed

Outputs of the
test

One set of results for every Oracle 9i AS instance monitored

401

M o n i t o r i n g

Measurements
made by the
test

O r a c l e

9 i

A p p l i c a t i o n

Measurement
Active thread groups:

S e r v e r s

Measurement
Unit
Number

A high value for this measure is
indicative of a high load on the
JVM.

Number

A high value for this measure is
indicative of a high load on the
JVM.

The free heap value governs the
performance of the JVM. A low
value could result in excessive
garbage collection, slowing down
responses/processing in the JVM.

This metric indicates the time
when the free heap reached its
minimum value.

A very high value for this
measure indicates heavy load on
the JVM.

Percent

If this value is 100%, then it
indicates that the JVM is running.
If it is 0, it indicates that the JVM
is not available or is not running.

Indicates the current number of
active thread groups in the JVM.
Active threads:
Indicates the current number of
active threads in the JVM.
Free heap:
Indicates the unused memory in
the JVM.

Min free heap:
Indicates the low water mark of
memory in the JVM since it
started.
Heap usage:
Indicates the used memory in
the JVM currently.
Max heap usage:
The high water mark of heap
used in the JVM since it was
started.
JVM availability:
Indicates the availability of the
Oracle 9i AS instance.

11.1.2

Interpretation

Java Transactions Test



402

M o n i t o r i n g



O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s



A look at the methods that took too long to execute, thus leading you to those methods that
may have contributed to the slowdown;



Single-click access to each invocation of a chosen method, which provides pointers to when
and where a method spent longer than desired;



A quick glance at SQL queries and Java errors that may have impacted the responsiveness of
the transaction;



eg_jtm.jar



aspectjrt.jar



aspectjweaver.jar



jtmConn.props



jtmLogging.props



jtmOther.props

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

4. Then, proceed to edit the start-up script of the Java application being monitored, and append the
following lines to it:
set JTM_HOME=<>
"-javaagent:%JTM_HOME%\aspectjweaver.jar"
"-DEG_JTM_HOME=%JTM_HOME%"

6. Finally, save the jtmConn.props file.
Then, proceed to configure the Java Transactions test as discussed in Section 9.1.9.1 of this document.

11.1.3

Java Classes Test

This test reports the number of classes loaded/unloaded from the memory.

Purpose

Reports the number of classes loaded/unloaded from the memory
404

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

405

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

Outputs of the
test
Measurements
made by the
test

One set of results for the server being monitored

Measurement
Unit

Measurement
Classes loaded:

Number

Indicates the number of classes
currently loaded into memory.

406

Interpretation
Classes are fundamental to the
design of Java programming
language.
Typically,
Java

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Classes unloaded:

Number

Indicates the number of classes
currently
unloaded
from
memory.

Total classes loaded:

Number

Indicates the total number of
classes loaded into memory
since the JVM started, including
those subsequently unloaded.

11.1.4

JVM Threads Test

This test reports the status of threads on the JVM, and also reveals resource-hungry threads, so that
threads that are unnecessarily consuming CPU resources can be killed.

Purpose

Reports the status of threads on the JVM, and also reveals resource-hungry threads,
so that threads that are unnecessarily consuming CPU resources can be killed

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal/remote agent

407

M o n i t o r i n g

Configurable
parameters for
the test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

408

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

409

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the
test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for the server being monitored

Measurement
Unit

Measurement
Total threads:

Interpretation

Number

Indicates the total number of
threads (including daemon and
non-daemon threads).
Runnable threads:

Number

The detailed diagnosis of this
measure, if enabled, provides the
name of the threads, the CPU
usage by the threads, the time
for which the thread was in a
blocked state, waiting state, etc.

Number

If a thread is trying to take a lock
(to enter a synchronized block),
but the lock is already held by
another thread, then such a
thread is called a blocked thread.

Indicates the current number of
threads in a runnable state.

Blocked threads:
Indicates the number of threads
that are currently in a blocked
state.

The detailed diagnosis of this
measure, if enabled, provides indepth information related to the
blocked threads.
410

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

Waiting threads:

S e r v e r s

Number

Indicates the number of threads
that are currently in a waiting
state.

Timed waiting threads:

Number

Indicates the number of threads
in a TIMED_WAITING state.

411

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Low CPU threads:

Number

Indicates the number of threads
that are currently consuming
CPU lower than the value
configured in the PCT LOW CPU
UTIL THREADS text box.
Medium CPU threads:

Number

Peak threads:

Number

Indicates the highest number of
live threads since JVM started.
Started threads:

Number

Indicates the the total number of
threads
started
(including
daemon,
non-daemon,
and
terminated) since JVM started.
Daemon threads:

Number

Indicates the current number of
live daemon threads.
Deadlock threads:

Number

Indicates the current number of
deadlocked threads.

412

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s



Go to the \jre\lib\management folder used by the WebLogic server, and edit the
management.properties file in that folder.



Append the following line to the file:
com.sun.management.enableThreadContentionMonitoring



Finally, save the file.

11.1.5

JVM Cpu Usage Test

Purpose

Reports the status of threads on the JVM, and also reveals resource-hungry threads,
so that threads that are unnecessarily consuming CPU resources can be killed

Target of the

An Oracle 9i AS
413

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

test
Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

414

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

15. ENCRYPTPASSWORD – Specify the encryption password here.
16. CONFIRM PASSWORD – Confirm the encryption password by retyping it here.
17. TIMEOUT - This parameter appears only if the MODE is set to SNMP. Here, specify
the duration (in seconds) within which the SNMP query executed by this test
should time out in the TIMEOUT text box. The default is 10 seconds.
18. PROFILER HOME – JIP (Java Interactive Profiler) is a high performance, low
overhead profiler that is written entirely in Java and used extensively to gather
performance data pertaining to a JVM. The eG agent comes bundled with JIP,
and takes the help of JIP to provide detailed diagnosis information related to the
CPU usage of the JVM. To make sure that this test contacts JIP for detailed
resource usage metrics, you need to indicate the location of the JIP in the
PROFILER HOME text box.

415

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for the server being monitored

Measurement

Measurement
Unit

416

Interpretation

M o n i t o r i n g

test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

CPU utilization of JVM:

Percent

Indicates the percentage of CPU
currently utilized by the JVM.

11.1.6

JVM Memory Usage Test

This test monitors every memory type on the JVM and reports how efficiently the JVM utilizes the
memory resources of each type.

Purpose

Monitors every memory type on the JVM and reports how efficiently the JVM utilizes
the memory resources of each type

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal/remote agent

417

M o n i t o r i n g

Configurable
parameters for
the test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

418

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

Outputs of the
test
Measurements
made by the

One set of results for every memory type on the JVM being monitored

Measurement

Measurement
Unit

419

Interpretation

M o n i t o r i n g

test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Initial memory:

The detailed diagnosis of this
measure, when enabled, reveals
the memory pools on the JVM,
the memory type of every pool,
and
the
memory
manager
managing the pool.

It includes the memory occupied
by all objects including both
reachable
and
unreachable
objects.

This is the difference between
Available memory and Used
memory.

Indicates the amount of memory
initially allocated at startup.

Used memory:
Indicates the amount of memory
currently used.
Available memory:
Indicates the amount of memory
guaranteed to be available for
use by the JVM.

Free memory:
Indicates the amount of memory
currently available for use by the
JVM.
Max free memory:

Ideally, the value of this measure
should be high.
MB

Indicates the maximum amount
of memory allocated for the JVM.
Used percentage:

Percent

Indicates the percentage of used
memory.

11.1.7

Ideally, the value of this measure
should be low. A very high value
of this measure could indicate
excessive memory consumption
by the JVM, which in turn, could
warrant further investigation.

JVM Uptime Test

This test helps track whether a scheduled reboot of the JVM has occurred or not.

Purpose

Helps track whether a scheduled reboot of the JVM has occurred or not

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal/remote agent

420

M o n i t o r i n g

Configurable
parameters for
the test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

421

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

Outputs of the
test
Measurements
made by the

One set of results for the server being monitored

Measurement

Measurement
Unit

422

Interpretation

M o n i t o r i n g

test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Has the JVM been restarted?:

If the value of this measure is No,
it indicates that the JVM has not
restarted. The value Yes on the
other hand implies that the JVM
has indeed restarted.

Indicates whether or not the JVM
has restarted during the last
measurement period.

The
numeric
values
that
correspond to the reboot states
discussed above are listed in the
table below:
State

Value

Yes

Secs

Administrators may wish to be
alerted if a JVM has been running
without a reboot for a very long
period. Setting a threshold for
this metric allows administrators
to determine such conditions.

Indicates the time period that
the JVM has been up since the
last time this test ran.

Total uptime of the JVM:
Indicates the total time that the
JVM has been up since its last
reboot.

423

M o n i t o r i n g

11.1.8

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

JVM Garbage Collections Test

Manual memory management is time consuming, and error prone. Most programs still contain leaks.
This is all doubly true with programs using exception-handling and/or threads. Garbage collection (GC)
is a part of a Java application’s JVM that automatically determines what memory a program is no
longer using, and recycles it for other use. It is also known as "automatic storage (or memory)
reclamation''. The JvmGarbageCollection test reports the performance statistics pertaining to the
JVM's garbage collection.

Purpose

Reports the performance statistics pertaining to the JVM's garbage collection

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal/remote agent

424

M o n i t o r i n g

Configurable
parameters for
the test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s



Using SNMP-based access to the Java runtime MIB statistics;



By contacting the Java runtime (JRE) of the application via JMX

To configure the test to use SNMP, select the SNMP option. On the other hand,
choose the JMX option to configure the test to use JMX instead. By default, the
JMX option is chosen here.
5. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
6. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
7. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
8. SNMPPORT – This parameter appears only if the MODE is set to SNMP. Here
specify the port number through which the server exposes its SNMP MIB. Ensure
that you specify the same port you configured in the management.properties file
in the \jre\lib\management folder used by the target application (refer
to the Monitoring Java Applications document).
9. SNMPVERSION – This parameter appears only if the MODE is set to SNMP. The
default selection in the SNMPVERSION list is v1. However, for this test to work,
you have to select SNMP v2 or v3 from this list, depending upon which version of
SNMP is in use in the target environment.
10. SNMPCOMMUNITY – This parameter appears only if the MODE is set to SNMP.
Here, specify the SNMP community name that the test uses to communicate
with the mail server. The default is public. This parameter is specific to SNMP v1
and v2 only. Therefore, if the SNMPVERSION chosen is v3, then this parameter
will not appear.

425

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

11. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
12. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
13. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
14. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

Outputs of the
test
Measurements
made by the

One set of results for every garbage collector configured on the WebSphere server
being monitored

Measurement

Measurement
Unit

426

Interpretation

M o n i t o r i n g

test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

No of garbage collections
started:

Number

Indicates the number of times
garbage collection started to
release
dead
objects
form
memory.
Time taken for garbage
collection:

Secs

Indicates the time taken to
perform the current garbage
collection operation.
Percent of time spent by JVM
for garbage collection:

Percent

Indicates the percentage of time
spent by JVM in garbage
collection.

11.1.9

JVM Memory Pool Garbage Collections Test

Purpose

Helps assess the impact of the garbage collection activity on the availability and
usage of memory in each memory pool of the JVM

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal/remote agent

427

M o n i t o r i n g

Configurable
parameters for
the test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
HOST - The host for which the test is to be configured
PORT - The port number at which the specified HOST listens
MEASURE MODE - This test allows you the option to collect the desired metrics
using one of the following methodologies:



By contacting the Java runtime (JRE) of the application via JMX



Using GC logs

To use JMX for metrics collections, set the MEASURE MODE to JMX.
On the other hand, if you intend to use the GC log files for collecting the
required metrics, set the MEASURE MODE to Log File. In this case, you would be
required to enable GC logging. The procedure for this has been detailed in the
Monitoring Java Applications document.
2. JMX REMOTE PORT – This parameter appears only if the MODE is set to JMX.
Here, specify the port at which the JMX listens for requests from remote hosts.
Ensure that you specify the same port that you configured in the
management.properties file in the \jre\lib\management folder used by
the target application (refer to the Monitoring Java Applications document).
3. USER, PASSWORD, and CONFIRM PASSWORD – These parameters appear only if
the MODE is set to JMX. If JMX requires authentication only (but no security), then
ensure that the USER and PASSWORD parameters are configured with the
credentials of a user with read-write access to JMX. To know how to create this
user, refer to the Monitoring Java Applications document. Confirm the password
by retyping it in the CONFIRM PASSWORD text box.
4. JNDINAME – This parameter appears only if the MODE is set to JMX. The JNDINAME
is a lookup name for connecting to the JMX connector. By default, this is
jmxrmi. If you have registered the JMX connector in the RMI registry using a
different lookup name, then you can change this default value to reflect the
same.
5. JREHOME - This parameter will be available only if the MEASURE MODE is set to
Log File. Specify the full path to the Java Runtime Environment (JRE) used by
the target application.
6. LOGFILENAME - This parameter will be available only if the MEASURE MODE is
set to Log File. Specify the full path to the GC log file to be used for metrics
collection.

Outputs of the
test
Measurements
made by the
test

One set of results for every GarbageCollector:MemoryPool pair on the JVM of the
server being monitored

Measurement
Unit

Measurement
Has garbage collection
happened:
Indicates
whether
collection
occurred
memory
pool
in
measurement period.

garbage
on
this
the
last

428

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

State

Value

Yes

Number

Indicates the number of time in
the last measurement pool
garbage collection was started
on this memory pool.
Initial memory before GC:

Indicates the initial amount of
memory (in MB) that this
memory pool requests from the
operating system for memory
management
during
startup,
before GC process.
Initial memory after GC:

Indicates the initial amount of
memory (in MB) that this
memory pool requests from the
operating system for memory
management
during
startup,
after GC process

429

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Max memory before GC:

Indicates the maximum amount
of memory that can be used for
memory management by this
memory pool, before GC
process.
Max memory after GC:

Indicates the maximum amount
of memory (in MB) that can be
used for memory management
by this pool, after the GC
process.

Committed memory before
GC:

Indicates the amount of memory
that
is
guaranteed
to
be
available for use by this memory
pool, before the GC process.
Committed memory after GC:

Indicates the amount of memory
that
is
guaranteed
to
be
available for use by this memory
pool, after the GC process.
Used memory before GC:

Indicates the amount of memory
used by this memory pool before
GC.
Used memory after GC:

Indicates the amount of memory
used by this memory pool after
GC.

430

Comparing the value of these two
measures for a memory pool will
provide you with insights into the
effectiveness of the garbage
collection activity.
If garbage collection reclaims a
large amount of memory from the
memory pool, then the Used
memory after GC may drop lower
than the Used memory before
GC. On the other hand, if the
garbage
collector
does
not
reclaim much memory from a
memory pool, or if the Java
application
suddenly
runs
a
memory-intensive process when
GC is being performed, then the
Used memory after GC value may
exceed the Used memory before
GC.

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

Percentage memory
collected:

S e r v e r s

Percent

Mins

Indicates the percentage of
memory collected from this pool
by the GC activity.

Collection duration:
Indicates the time taken by this
garbage collector for collecting
unused memory from this pool.

11.1.10

JMX Connection to JVM

Purpose

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal/remote agent

431

M o n i t o r i n g

Configurable
parameters for
the test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Outputs of the
test
Measurements
made by the
test

One set of results for the Java application being monitored

Measurement
Unit

Measurement
JMX availability:

Percent

Indicates whether the target
application is available or not
and whether JMX is enabled or
not on the application.

JMX response time:

Secs

Indicates the time taken to
connect to the JMX agent of the
Java application.
Has the PID changed?

Interpretation
If the value of this measure is
100%, it indicates that the Java
application is available with JMX
enabled. The value 0 on the other
hand, could indicate one/both the
following:



The
Java
application is unavailable;



The
Java
application is available,
but JMX is not enabled;

A high value could indicate a
connection bottleneck.

Indicates whether/not the
process ID that corresponds to
the Java application has
changed.

432

M o n i t o r i n g

11.1.11

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

JVM File Descriptors Test

This test reports useful statistics pertaining to file descriptors.

Purpose

Reports useful statistics pertaining to file descriptors

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal/remote agent

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

One set of results for the Java application being monitored

Measurement
Unit

Measurement
Open file descriptors in JVM:

Number

Indicates the number of file
descriptors currently open for
the application.
Maximum file descriptors in
JVM:

Number

Indicates the maximum number
of file descriptors allowed for the
application.
File descriptor usage by JVM:

Percent

Indicates the file descriptor
usage in percentage.

433

Interpretation

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

11.2 The Oracle JDBC Layer
The tests associated with this layer (see Figure 11.3) enable administrators to:



Measure the health of the JDBC connections in every instance of the server



Monitor the usage of the connection cache



Determine the number and type of transactions executing on the server

Figure 11.3: The tests associated with the Oracle==== JDBC layer

11.2.1

Oracle 9i Drivers Test

This test reports the performance metrics related to the JDBC Connection in an instance of the Oracle
9i application server.

Purpose

Reports the performance metrics related to the JDBC Connection in Oracle 9i
application server instance

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT

4. HOMEDIR – The absolute path of the directory in which the Oracle 9i application
server has been installed

Outputs of the
test

One set of results for every instance of the Oracle 9i AS monitored

434

M o n i t o r i n g

Measurements
made by the
test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Measurement
Unit

Measurement
Threads creating
connections:

Interpretation

Number

Indicates the current number of
threads creating connections.
Avg connection create time:

Secs

An increase in this metric could
indicate a bottleneck in the
database/database
connection
points.

Secs

A high value for this measure is
indicative of a bottleneck during
database access.

Conns/Sec

A very high value for this
measure indicates a heavy load
on database access.

Conns/Sec

The value of this measure must
be equal to the Connections open.
If this value is consistently less
than Connections open, then it
indicates a potential problem that connections are hanging on
to the database server.

Indicates the average time spent
creating connections during the
last measurement period.
Max connection create time:
Indicates the high water mark
indicating the maximum time
spent creating connections since
the server was started.
Connections open:
Indicates the number of
connections that have been
opened per second in the last
measurement period.
Connections closed:
Indicates the number of
connections that have been
closed per second.

11.2.2

Oracle 9i Connection Cache Test

This test reports the performance metrics related to the connection cache of an instance of the
Oracle9i application server.

Purpose

Reports the performance metrics related to the connection cache of every instance
of the Oracle9i application server

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal agent

435

M o n i t o r i n g

Configurable
parameters for
the test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

4. HOMEDIR – The absolute path of the directory in which the Oracle 9i application
server has been installed

Outputs of the
test
Measurements
made by the
test

One set of results for every instance of the Oracle 9i AS monitored

Measurement
Unit

Measurement
Free cache size:

Interpretation

Number

Indicates the number of free
slots in the connection cache.
Cache size:

Number

Indicates the total size of the
connection cache.
Cache hits:

Conns/Sec

Reading from the cache is less
expensive than reading from disk.
Therefore, the higher this value,
the better.

Conns/Sec

Reading from the cache is less
expensive than reading from disk.
Therefore, the lower this value,
the better.

Indicates the number of times a
request for connection has been
fulfilled by the cache.
Cache misses:
Indicates the rate at which the
cache failed to fulfill a request
for connection.

11.2.3

Oracle 9i Transactions Test

This test reports the performance metrics related to the transactions occurring on the Oracle9i
application server.

Purpose

Reports the performance metrics related to the transactions occurring on the
Oracle9i application server

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal agent

436

M o n i t o r i n g

Configurable
parameters for
the test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

4. HOMEDIR – The absolute path of the directory in which the Oracle 9i application
server has been installed

Outputs of the
test
Measurements
made by the
test

One set of results for every instance of the Oracle 9i AS monitored

Measurement
Active transactions:

Measurement
Unit
Number

Indicates the current number of
open transactions.

Transactions commits:

Interpretation
A high value of this measure may
indicate a large number of active
transactions. Alternatively, this
may also indicate that due to
some reasons the users are not
able to complete the transactions.

Trans/Sec

Indicates the rate at which the
transactions were committed.
Transaction rollbacks:

Trans/Sec

Indicates the rate at which
transactions were rolled back
during the last measurement
period.

A high value here would mean
that more number of transactions
are being rolled back.

11.3 The Oracle Web Modules Layer
The Oracle9iWebModules test associated with this layer tracks the requests to every web module on each
of the monitored Oracle 9i AS instances.

437

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Figure 11.4: The tests associated with the Oracle Web Modules layer

11.3.1

Oracle 9i Web Modules Test

This test reports the performance metrics related to every web module in every instance of the
Oracle9i application server.

Purpose

Reports the performance metrics related to every web module in every instance of
the Oracle9i application server

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

4. HOMEDIR – The absolute path of the directory in which the Oracle 9i application
server has been installed

Outputs of the
test
Measurements
made by the

One set of results for every web module on every instance of the Oracle 9i AS
monitored

Measurement

Measurement
Unit

438

Interpretation

M o n i t o r i n g

test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Requests active:

Number

A high value of this measure
indicates a heavy load on the web
module. An increase in requests
running may indicate an increase
in user workload. Alternatively, a
slowdown of the application
server may also cause the
requests that are simultaneously
executing to increase.

Secs

A very high value for this
measure indicates that the web
module
is
handling
many
requests.

Trans/Sec

An increase in this value may be
indicative of a problem in the
application server. This increase
could also be attributed to a
problem in database tier provided
the application is using the
database
for
servicing
the
request.

Indicates the current number of
threads servicing web requests.

Requests completed:
Indicates the average time spent
servicing web requests during
the last measurement period.
Avg request process time:
Indicates the average time spent
servicing web requests during
the last measurement period.

Max request process time:

Secs

Indicates the high water mark
indicating the maximum time
spend servicing a web request
Avg context resolve time:

Secs

A very high value is an indication
of heavy load on the web module.

Secs

Comparing the total request
processing time with the context
resolution time and request
parsing time, can provide an
indication of where a request is
spending time in the O9i AS
instance.

Indicates the average time spent
to create/find the servlet context
during the last measurement
period.
Avg request parse time:
Indicates the average time spent
to read/parse requests during
the last measurement.

11.4 The Oracle Web Context Layer
Using the test associated with this layer, administrators can monitor the session load on every web
context on an Oracle 9i AS instance, and can determine whether any web context is taking too much
time to create/locate a servlet instance.

439

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Figure 11.5: The tests associated with the Oracle Web Context layer

11.4.1

Oracle 9i Web Contexts Test

This test reports the performance metrics related to every web context on each instance of the Oracle
9i AS.

Purpose

Reports the performance metrics related to every web context on each instance of
the Oracle 9i AS

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

4. HOMEDIR – The absolute path of the directory in which the Oracle 9i application
server has been installed

Outputs of the
test
Measurements
made by the
test

One set of results for every web context on each instance of the Oracle 9i AS
monitored

Measurement
Active sessions:

Measurement
Unit
Number

Indicates the current number of
active sessions.

440

Interpretation
A high value may indicate that
there is a high load on the web
context.

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Avg session lifetime:

Secs

Indicates the average session
life time during the last
measurement period.
Avg servlet resolve time:

A high value may indicate that a
session that was opened on this
web context may not be closed
properly.

Secs

Indicates the maximum time
spent to create/locate the servlet
instance (within the servlet
context).
Avg servlet resolve time:

Secs

Indicates the average time spent
to create/locate the servlet
instance (within the servlet
context)
during
the
last
measurement period.

11.5 The Oracle J2EE Layer
To monitor the health of the JSPs and servlets on an Oracle 9i AS instance, use the tests associated
with this layer (see Figure 11.6).

Figure 11.6: The tests associated with the Oracle J2EE layer

11.5.1

Oracle 9i Jsps Test

This test reports the performance metrics related to the JSPs deployed in an Oracle9i application
server instance. In order to enable users to easily manage and monitor the JSPs deployed on an
Oracle 9i application server, the eG Enterprise suite provides the Click Here hyperlink, which when
clicked allows users to add, modify, or delete groups of JSPs. Note that by default eG Enterprise monitors

only those JSPs that are part of a group.
Purpose

Reports the performance metrics related to the JSPs deployed in an Oracle9i
application server instance

Target of the
test

An Oracle 9i AS

Agent

An internal agent
441

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

deploying the
test
Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT - In the PORT text box, it is recommended that you provide the port at
which the OPMN (Oracle Process Manager and Notification) process of the Oracle
application server instance listens. To know at which port OPMN listens, click on
the
Ports
tab
in
the
following
URL:
http://:. This tab lists the port
numbers that were assigned to the services executing on the Oracle application
server. The port number displayed against the Oracle notification server
request port entry is the OPMN port, and the same should be specified in the
PORT text box.
4. HOMEDIR – The absolute path of the directory in which the Oracle 9i application
server has been installed
5. AUTODISCOVERY – By default, eG Enterprise allows administrators to configure
JSP groups using the eG administrative interface, and reports metrics pertaining
to every group so created. Accordingly, by default, AUTODISCOVERY is set to
NO. If you want JSPs to be discovered and monitored automatically, then select
the YES option against AUTODISCOVERY. When this is done, the eG agent
automatically discovers all the JSPs on the server, and reports one set of
measures for every JSP so discovered.

Outputs of the
test
Measurements
made by the
test

One set of results for every JSP group monitored or for every JSP auto-discovered
(as the case may be)

Measurement
Threads serving JSPs:

Measurement
Unit
Number

Indicates the current number of
active requests for the JSP.

442

Interpretation
If
a
majority
of
the
threads/processes are in use
simultaneously to serve requests
for a specific JSP, this may be
indicative of a problem with the
design of this page. Further
investigation
is
needed
to
determine the cause of the
bottleneck - whether it is the
processing of the JSP, whether it
is a bottleneck in the database
tier, whether the database query
(ies)
are
non-optimal
etc.
Alternatively, a slowdown of the
application server may also cause
the
requests
that
are
simultaneously
executing
to
increase.

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Requests completed:

Reqs/Sec

Comparing this metric across
JSPs can indicate which pages are
most accessed. Optimizing the
most heavily accessed pages can
result
in
a
significant
improvement
in
the
userperceived performance of that
web application.

Secs

An increase in this value may be
indicative of a problem in the
application server/JSP logic.

Indicates the rate at which
requests were processed by this
JSP.

Avg request process time:
Indicates the average time spent
in servicing the JSP during the
last measurement period.
Max request process time:

Secs

Indicates the maximum time
spent servicing a JSP since the
server started.

11.5.2

Oracle 9i Servlets Test

This test reports the performance metrics pertaining to the servlets deployed in an Oracle 9i AS
instance. In order to enable users to easily manage and monitor servlets, the eG Enterprise suite
provides the Click Here hyperlink, which when clicked allows users to add, modify, or delete servlet
groups. Note that by default eG Enterprise monitors only those servlets that are part of a group.

Purpose

Reports the performance metrics related to the servlets deployed in an Oracle9i
application server instance

Target of the
test

An Oracle 9i AS

Agent
deploying the
test

An internal agent

443

M o n i t o r i n g

Configurable
parameters for
the test

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

4. HOMEDIR – The absolute path of the directory in which the Oracle 9i application
server has been installed

5. AUTODISCOVERY – By default, eG Enterprise allows administrators to configure
servlet groups using the eG administrative interface, and reports metrics
pertaining to every group so created. Accordingly, by default, AUTODISCOVERY
is set to NO. If you want servlet s to be discovered and monitored automatically,
then select the YES option against AUTODISCOVERY. When this is done, the eG
agent automatically discovers all the servlet s on the server, and reports one set
of measures for every servlet so discovered.

Outputs of the
test
Measurements
made by the
test

One set of results for every servlet group configured or for every discovered servlet
(as the case may be)

Measurement
Threads for servlet:

Measurement
Unit
Number

If
a
majority
of
the
threads/processes are in use
simultaneously to serve requests
for a specific servlet, this may be
indicative of a problem with a
specific servlet or one of the
components
used
by
it.
Alternatively, a slowdown of the
application server may also cause
the
requests
that
are
simultaneously
executing
to
increase for all servlets.

Reqs/Sec

A very high value for this
measure indicates that the servlet
has been accessed many times.

Indicates the current number of
threads servicing this servlet.

Requests completed:

Interpretation

Indicates the rate of calls to the
service() method.

444

M o n i t o r i n g

O r a c l e

9 i

A p p l i c a t i o n

S e r v e r s

Avg request process time:

Secs

Indicates the average time spent
in servicing the servlet during
the last measurement period.

Max request process time:

Secs

Indicates the maximum time
spent on a servlet’s service()
call.

445

Comparing the request processing
time
across
servlets,
an
administrator
can
determine
which servlet(s)
can be
a
performance
bottleneck.
An
increase in response time of a
servlet with load, could indicate a
design problem with the servlet eg., use of a non-optimal
database
query,
database
connection
pool
shortage,
contention for shared resources,
etc.

M o n i t o r i n g

O r a c l e

1 0 g

A p p l i c a t i o n

S e r v e r s

Chapter

12
Monitoring Oracle 10g Application
Servers
Oracle Application Server 10g offers a comprehensive solution for developing, integrating, and
deploying applications, portals, and Web services. Based on a powerful and scalable J2EE server,
Oracle Application Server 10g provides complete business integration and business intelligence suites,
and best-of-breed portal software. Further, it is designed for grid computing and full lifecycle support
for Service-Oriented Architecture (SOA).
In order to ensure that the quality of the business-critical services supported by the Oracle Application
server 10g does not suffer due to incapacities of the application server, it is essential that the server is
monitored 24 x 7, and its performance fine-tuned to meet the demands of the service users.
eG Enterprise provides out-of-the-box an Oracle Application monitoring model, that caters to the
specific monitoring needs of the Oracle 10g application servers (see Figure 12.1).

Figure 12.1: The layer model of the Oracle 10G application server
As you can see, the monitoring model depicted by Figure 12.1 is the same as that which eG Enterprise
offers for the Oracle 9i Application server (see Figure 11.1). The tests associated with every layer of
Figure 12.1, and the metrics that each test reports, have therefore been discussed already in Chapter
11 of this document, which focuses on the O9i Application Server model.
The difference however lies in the Oracle J2EE layer, which supports two additional tests for the Oracle
Application model– the OracleEjbs test and the OracleJmsStore test.

446

M o n i t o r i n g

O r a c l e

1 0 g

A p p l i c a t i o n

S e r v e r s

Note:
To effectively monitor an Oracle application server on Unix, ensure that the install user of the
application server and that of the eG agent (which is monitoring the application server) are the
same.

Hence, the sections to come will discuss only the Oracle J2EE layer and the two new tests associated
with it.

12.1 The Oracle J2EE Layer
The tests associated with this layer monitor the health of the following:



JSPs



Servlets



The EJB container



Java Message Service (JMS)

Figure 12.2: The tests associated with the Oracle J2EE layer

12.1.1

Oracle Ejbs Test

This test monitors the state of EJB component groups hosted on an Oracle application server (10g or
higher). Use the Click here hyperlink in the test configuration page to configure the EJB groups that
need to be monitored by the eG Enterprise suite. By default, the eG Enterprise system will monitor only those

EJBs that are part of a group.

Purpose

Monitors the state of EJB component groups hosted on an Oracle application server
(10g or higher)

Target of the
test

An Oracle Application Server 10g or higher

Agent
deploying the

An internal agent

447

M o n i t o r i n g

O r a c l e

1 0 g

A p p l i c a t i o n

S e r v e r s

test
Configurable
parameters for
the test

4. HOMEDIR – The absolute path of the directory in which the Oracle application
server has been installed

5. AUTODISCOVERY – By default, the eG suite allows administrators to configure
EJB groups using the eG administrative interface, and reports metrics pertaining
to every group so created. Accordingly, by default, AUTODISCOVERY is set to
NO. If you want EJBs to be discovered and monitored automatically, then select
the YES option against AUTODISCOVERY. When this is done, the eG agent
automatically discovers all the EJBs on the application server, and reports one
set of measures for every EJB on the server.

6. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
Enterprise suite embeds an optional detailed diagnostic capability. With this
capability, the eG agents can be configured to run detailed, more elaborate tests
as and when specific problems are detected. To enable the detailed diagnosis
capability of this test for a particular server, choose the On option. To disable
the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be
available only if the following conditions are fulfilled:

Outputs of the
test
Measurements
made by the
test



The eG manager license should allow the detailed diagnosis capability



Both the normal and abnormal frequencies configured for the detailed
diagnosis measures should not be 0.

One set of results for every EJB group configured or every EJB auto-discovered

Measurement
Unit

Measurement
Avg activation time:

Secs

Indicates the average time taken
for activating this bean/ beans in
this EJB group.
Avg creation time.:

Secs

Indicates the average time taken
for creating this bean/ beans in
this EJB group.

448

Interpretation

M o n i t o r i n g

O r a c l e

1 0 g

A p p l i c a t i o n

Avg passivation time:

S e r v e r s

Secs

Indicates the average time taken
for passivating this bean/ beans
in this EJB group.
Avg post create time:

Secs

Indicates the average time taken
for a post create call on this
bean/ beans in this EJB group.
Avg removal time:

Secs

Indicates the average time taken
for removing this bean/ beans in
this EJB group.
Bean activations:

Number

Indicates the number of times
this bean/ beans in this EJB
group were activated.
Bean creations:

Number

Indicates the number of times
this bean/beans in this EJB
group were created.
Bean passivations:

Number

Indicates the number of times
this bean/ beans in this EJB
group were passivated.
Bean postcreations:

Number

Indicates the number of times
this bean/ beans in this EJB
group were post created.
Bean removals:

Number

Indicates the number of times
this bean/ beans in this EJB
group were removed.
Current threads activate:

Number

Indicates the number of threads
that are currently used for
activating this bean/ beans in
this EJB group.
Current threads creation:

Number

Indicates the number of threads
that are currently used for
invoking a create call on this
bean/ beans in this EJB group.

449

M o n i t o r i n g

O r a c l e

1 0 g

A p p l i c a t i o n

Current threads passivate:

S e r v e r s

Number

Indicates the number of threads
that are currently used for
passivating this bean/ beans in
this EJB group.
Current threads postcreate:

Number

Indicates the number of threads
that are currently used for
placing a postcreate call on this
bean/ beans in this EJB group.
Current threads remove:

Number

Indicates the number of threads
that are currently used for
removing this bean/ beans in
this EJB group.

12.1.2

Oracle Jms Store Test

This test monitors the health of the Java Message Service (JMS) store that the Oracle Enterprise
Messaging Service (OEMS) supports. OEMS is a standards-based (JMS, JCA) messaging platform
offering a comprehensive set of messaging and integration features for developing and deploying
distributed applications in a service-oriented architecture (SOA) environment. OEMS also forms the
underlying messaging infrastructure for Oracle’s Enterprise Service Bus (ESB) and the BPEL Process
Manager components of Oracle Fusion Middleware.

Purpose

Monitors the health of the Java Message Service (JMS) specification that the Oracle
Enterprise Messaging Service (OEMS) supports

Target of the
test

An Oracle Application Server 10g or higher

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

4. HOMEDIR – The absolute path of the directory in which the Oracle application
server has been installed

Outputs of the
test

One set of results for the Oracle Application server 10g that is monitored

450

M o n i t o r i n g

Measurements
made by the
test

O r a c l e

1 0 g

A p p l i c a t i o n

S e r v e r s

Measurement
Unit

Measurement
Messages count:

Number

Indicates the total number of
messages in the store – both
committed and rolledback.
Messages dequeued:

Number

Indicates the number of
dequeued messages.
Messages discarded:

Number

Indicates the number of
messages discarded from the
store.
Messages enqueued:

Number

Indicates the number of
enqueued messages.
Messages expired:

Number

Indicates the number of expired
messages.
Messages paged in:

Number

Indicates the number of paged in
messages.
Messages paged out:

Number

Indicates the number of paged
out messages.
Messages pending:

Number

Indicates the number of
messages pending completion.
Messages recovered:

Number

Indicates the number of
recovered messages.
Messages rolledback:

Number

Indicates the number of
messages that were rolled back.
Store size:

Indicates the size of the JMS
store.

451

Interpretation

M o n i t o r i n g

O r a c l e

F o r m s

S e r v e r s

Chapter

13
Monitoring Oracle Forms Servers
An important component of the Oracle Internet Platform is the Oracle Forms Server. This application
server is optimized to deploy Oracle Forms applications in a multi-tiered environment. It delivers the
application infrastructure and the event model to ensure that Internet-based Forms applications
automatically scale and perform over any network.
Oracle Forms Developer and Oracle Forms Services provide a complete application framework for
optimal deployment of Oracle Forms applications on the Internet. The Oracle Forms Developer enables
business developers to build Java applications that are optimized for the Internet without writing any
Java code. This developer is specifically designed and optimized to build transactional database
applications for the Oracle8i/9i database. It integrates with the Oracle Designer to visually capture
business requirements and transform them into physical designs. Using Oracle Forms Developer, you
can customize Oracle's pre-packaged applications, to suit the needs of your organization.
It is therefore evident that even the slightest of disturbances in the overall performance or internal
operation of the Oracle Forms server, can adversely impact the scalability and network compatability
of the Forms applications it supports. If such an eventuality is to be prevented, then it is
recommended that you continuously monitor the Oracle Forms server for any minor/major deviations.
eG Enterprise provides an exclusive Oracle Forms9i monitoring model (see Figure 13.1) that executes
tests on the Forms server to keep track of its internal health and external availability, and alerts
administrators of impending performance issues.

Figure 13.1: The layer model of an Oracle Forms server

452

M o n i t o r i n g

O r a c l e

F o r m s

S e r v e r s

The metrics that these tests collect from the Oracle Forms server, enable administrators to find quick
and accurate answers to the following performance queries:



Are all the critical Forms processes currently running?



Is the resource consumption of the Forms processes optimal?



How is the session load on the server? Are there too many sessions currently active on the
server? Which users have initiated these sessions?



Are there any idle sessions?



What is the average session duration? Have sessions remained open for unreasonably long
periods?



Is the Forms server responding slowly to user requests? If so, which user do these requests
pertain to?



Is any user's processes consuming too much CPU and memory resources?

The sections to come will discuss the top 3 layers of Figure 13.1, as all other layers have been
discussed elaborately in the Monitoring Unix and Windows Servers document.

Note:
Before attempting to monitor an Oracle Forms server, ensure that its tracing capability is enabled.

13.1 The Forms Processes Layer
This layer is associated with an F9iProcess test that reports how well the critical Forms server processes
utilize the CPU and memory resources.

Figure 13.2: The tests associated with the Forms Processes layer

453

M o n i t o r i n g

13.1.1

O r a c l e

F o r m s

S e r v e r s

F9i Processes Test

This test reports the memory and CPU usage of the Oracle Forms 9i server processes.

Purpose

Reports the memory and CPU usage of the Oracle Forms 9i server processes

Target of the
test

An Oracle Forms Server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT - The port to which the specified HOST listens
4. FORMWORKDIR – The path to the install directory of the Oracle Forms 9i server.
Typically, this will be the /Forms90/.

5. FORMSRUNTIME - The value, "ifweb90.exe", is displayed here. This is the Forms
server runtime executable.

6. ORAHOMEDIR - The install directory of the Oracle 9i server. This specification
becomes more important when more than one Oracle 9i AS installation exists on
a host.

7. TRCCLEANUPTIME - For Oracle 9i Forms monitoring, eG requires tracing to be
enabled for the server. The trace files corresponding to completed sessions are
automatically cleaned by the eG agent. The frequency with which these files are
to be cleared from the server is to be specified in the TRCCLEANUPTIME
textbox. The default value displayed in the TRCCLEANUPTIME text box is 30
minutes.

Outputs of the
test
Measurements
made by the
test

One set of results for every Oracle Forms server monitored

Measurement
Number of processes
running:

Measurement
Unit
Number

This value indicates if too many
or
too
few
instances
corresponding to the specified
process are executing on the
host.

Percent

A very high value could indicate
that the specified process is
consuming
excessive
CPU
resources.

Indicates the number of Forms
processes currently running.
CPU usage:
Indicates the percentage of CPU
time utilized by the Forms
processes.
Memory usage:

Interpretation

Percent

Indicates the percentage of
memory utilized by the Forms
processes.

454

M o n i t o r i n g

O r a c l e

F o r m s

S e r v e r s

13.2 The Forms Server Layer
This layer tracks the user sessions to the Forms server to identify sessions that have been open for an
unreasonably long time. In addition, the layer also measures the responsiveness of the Forms server
to client requests.

Figure 13.3: Tests associated with the Forms Server layer

13.2.1

F9i Sessions Test

This test monitors the user sessions to the Oracle Forms 9i server.

Purpose

Monitors the user sessions to the Oracle Forms 9i server

Target of the
test

An Oracle Forms Server

Agent
deploying the
test

An internal agent

455

M o n i t o r i n g

Configurable
parameters for
the test

O r a c l e

F o r m s

S e r v e r s

5. FORMSRUNTIME - The value, "ifweb90.exe", is displayed here. This is the Forms
server runtime executable.

6. ORAHOMEDIR - The install directory of the Oracle 9i server. This specification
becomes more important when more than one Oracle 9i AS installation exists on
a host.

8. SESSIONIDLETIME - One of the measures returned by this test, is the number of
idle sessions. While taking a count of idle sessions, the test will consider only
those sessions that have remained idle for the duration specified in the
SESSIONIDLETIME text box. The default value displayed here is 10. This means
that the test will track those sessions that have been idle for 10 minutes or
more. You can change this value, if required.

Outputs of the
test
Measurements
made by the
test

One set of results for every Oracle Forms server monitored

Measurement
Unit

Measurement
Total sessions:

Number

Tracking the value of this
measure over time provides an
idea of the workload of the Forms
server.

Number

A high value may indicate that
there is a heavy processing load
on the server.

Indicates the total number of
Forms sessions currently
running.
Active sessions:
Indicates the total number of
currently active Forms sessions.
Idle sessions:

Interpretation

Number

Indicates the total number of
currently idle Forms sessions.
Sessions added:

Number

Indicates the total number of
Forms sessions newly added in
the last measurement period.
Sessions removed:

Number

Indicates the total number of
Forms sessions removed in the
last measurement period.

456

This metric can indicate unusual
session disconnects.

M o n i t o r i n g

O r a c l e

F o r m s

S e r v e r s

Avg session duration:

Mins

Indicates the average duration of
all current sessions.

13.2.2

By tracking the average duration
of current sessions and the
number of simultaneous sessions,
a Forms administrator can obtain
critical information for capacity
planning.

F9i Response Test

This test measures the responsiveness of the Oracle Forms 9i server to user requests.

Purpose

Measures the responsiveness of the Oracle Forms 9i server to user requests

Target of the
test

An Oracle Forms Server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

5. FORMSRUNTIME - The value, "ifweb90.exe", is displayed here. This is the Forms
server runtime executable.

6. ORAHOMEDIR - The install directory of the Oracle 9i server. This specification
becomes more important when more than one Oracle 9i AS installation exists on
a host.

Outputs of the
test
Measurements
made by the
test

One set of results for every Oracle Forms server monitored

Measurement
Unit

Measurement
Forms request rate:

Reqs/Sec

Indicates the rate of requests
processed by the Forms server
during the last measurement
period.

457

Interpretation
A high value may indicate that
there is a heavy load on the
Forms server

M o n i t o r i n g

O r a c l e

F o r m s

S e r v e r s

Database request rate:

Reqs/Sec

A high value may indicate that
there is a heavy load on the
database server

Secs

A sudden increase in response
time could indicate a heavy
network traffic.

Secs

A sudden increase in response
time is indicative of a potential
performance bottleneck on the
Forms server.

Secs

A sudden increase in response
time is indicative of a potential
performance bottleneck on the
database server.

Indicates the rate of requests
from the Forms server to the
database server during the last
measurement period
Client/network response
time:
Indicates the average time spent
by
requests
in
the
last
measurement period waiting for
responses from the client. This
measure includes the client think
time and the network latency.
Forms server response time:
Indicates the average processing
time of requests at the Forms
server.
Database response time:
Indicates the average response
time of the database server for
servicing requests passed to it
from the Forms server.

13.3 The Forms User Layer
Use the F9iUsers test associated with this layer to track the user activity on the Forms server.

Figure 13.4: Tests associated with the Forms User layer

13.3.1

F9i Users Test

This test reports general statistics pertaining to the database users.

Purpose

Reports general statistics pertaining to the database users
458

M o n i t o r i n g

O r a c l e

F o r m s

S e r v e r s

Target of the
test

An Oracle Forms Server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

5. FORMSRUNTIME - The value, "ifweb90.exe", is displayed here. This is the Forms
server runtime executable.

6. ORAHOMEDIR - The install directory of the Oracle 9i server. This specification
becomes more important when more than one Oracle 9i AS installation exists on
a host.

Outputs of the
test
Measurements
made by the
test

One set of results for every Oracle Forms server user being monitored

Measurement
Unit

Measurement
Forms request rate:

Reqs/Sec

A comparison of this measure
across users can be used to
determine which user(s) are
heavily using the Forms server.

Reqs/Sec

A comparison of this measure
across users can indicate the top
users of the Forms database.

Secs

A sudden increase in response
time could be indicative of heavy
network traffic.

Secs

A sudden increase in response
time is indicative of a potential
performance bottleneck in the
Forms server.

Indicates the rate of requests
received by a Forms server for a
specific user during the last
measurement period.
Database request rate:
Indicates the rate of requests to
the database issued by the
Forms server for a specific user
during the last measurement
period.
Client/network response
time:
Indicates the response time of
the client and network for this
database user.
Forms server response time:

Interpretation

Indicates the response time of
the Forms server for a particular
database user.

459

M o n i t o r i n g

O r a c l e

F o r m s

S e r v e r s

Database response time:

Secs

A sudden increase in response
time is indicative of a potential
performance bottleneck on the
database server.

Number

A high value may indicate that
there is a high load on the server.

Indicates the response time of
the database for a particular
database user.
Sessions:
Indicates the total number of
Forms sessions running for a
particular database user.
Avg session duration:

Mins

Indicates the average duration of
the Forms sessions running for a
particular database user.
Memory usage:

Percent

A sudden increase in memory
utilization for a process may be
indicative of memory leaks in the
application.

Percent

A very high value could indicate
that the processes are consuming
excessive CPU resources.

Indicates the percentage of
memory utilized by the Forms
processes corresponding to a
particular database user.
CPU usage:
Indicates the percentage of CPU
time utilized by the Forms
processes corresponding to a
particular database user.

460

M o n i t o r i n g

B o r l a n d

E n t e r p r i s e

S e r v e r s

( B E S )

Chapter

14
Monitoring Borland Enterprise
Servers (BES)
The Borland Enterprise Server is a set of services and tools that enable users to build, deploy, and
manage enterprise applications in any corporate environment. These applications provide dynamic
content by using JSP, servlets, and Enterprise Java Bean (EJB) technologies.
Just like any other application server, it is imperative to monitor the BES also, so as to ensure the
stability of the mission-critical services it supports.
eG Enterprise has developed a specialized Borland monitoring model (see Figure 14.1), that monitors
all internal and external parameters that can affect the performance of the BES.

Figure 14.1: The layer model of a Borland Enterprise server
Every layer of Figure 14.1 is mapped to a set of tests, which when executed on the BES, extracts
critical statistics that can enable administrators to determine the following:



Does the BES management agent have adequate memory to discharge its duties?



Is sufficient memory available to the BES partitions?



Where is BES spending too much time? - is it on any of the CMP-related activities? is it on any
JDBC1 or JDBC2 activity? is it on activating or passivating EJBs? or is it on specific
transactions?

461

M o n i t o r i n g

B o r l a n d

E n t e r p r i s e

S e r v e r s

( B E S )

The following sections discuss each of the top 3 layers of Figure 14.1 elaborately. The other layers
have already been dealt with in the Monitoring Unix and Windows Servers document.

14.1 The Agent Layer
To monitor the memory usage of the BES management agent, use the AgentStat test associated with
this layer.

Figure 14.2: The tests associated with the Agent layer

14.1.1

Agent Statistics Test

This test reports the runtime statistics pertaining to a BES management agent.

Purpose

Reports the runtime statistics pertaining to a BES management agent

Target of the
test

A BES server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT - The smart agent port number
4. MGMT_PORT_NUMBER – The port number where the management agent listens
5. USER – The name of a BES user
6. PASSWORD – The password of the specified USER
7. CONFIRM PASSWORD – Confirm the PASSWORD by retyping it here.
8. REALM - The BES server realm

Outputs of the
test
Measurements
made by the

One set of results for every BES server monitored

Measurement

Measurement
Unit

462

Interpretation

M o n i t o r i n g

test

B o r l a n d

E n t e r p r i s e

S e r v e r s

Memory available:

( B E S )

Indicates the heap available for
the management agent.
Memory used:

Indicates the amount of heap
used by the management agent.
Max memory used:

Indicates the maximum amount
of
heap
used
by
the
management agent.
Active threads:

Number

Indicates the current number of
active
threads
in
the
management agent
Num of partitions:
Indicates
the
number
partitions in use under
management agent

Number
of
this

14.2 The Partition Layer
The tests associated with the Partition layer help administrators determine how efficiently the BES
performs garbage collection, and how well its partitions function.

Figure 14.3: The tests associated with the Partition layer
The JVMGC test has already been discussed while discussing the tests associated with a WebLogic
server. This section will therefore deal with the PartitionStat test only.

14.2.1

Partition Stat Test

The PartitionStat test reports the runtime statistics of a BES partition.

Purpose

Reports the runtime statistics pertaining of a BES partition

Target of the

A BES server
463

M o n i t o r i n g

B o r l a n d

E n t e r p r i s e

S e r v e r s

( B E S )

test
Agent
deploying the
test

An internal Agent

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

One set of results for every BES partition monitored

Measurement
Unit

Measurement
Memory available:

Interpretation

Indicates the heap available for
the partition.
Memory used:

Indicates the amount of heap
used by the partition.
Max memory used:

Indicates the maximum amount
of heap used by the partition.
Active thread count:

Number

Indicates the current number of
active threads in the partition
Deployed archives:

Number

Indicates the number of archives
deployed in the partition

14.3 The Partition Services Layer
The tests mapped to this layer reports the time taken by BES for performing the following (see Figure
14.4):



CMP and other activities



JDBC1 and JDBC2 activities



Activating and Passivating stateful session beans



Different types of transactions

464

M o n i t o r i n g

B o r l a n d

E n t e r p r i s e

S e r v e r s

( B E S )

Figure 14.4: The tests associated with the Partition Services layer

14.3.1

CMP Test

This test reports the time taken by the BES EJB container for performing CMP related activities.

Purpose

Reports the time taken by the BES EJB container for performing CMP related
activities

Target of the
test

A BES server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

One set of results for every BES partition monitored

Measurement
Unit

Measurement
EntityHome:

Secs

Indicates the time spent in the
container,
implementing
EJBHome-related
operations
specific to Entity beans.

465

Interpretation

M o n i t o r i n g

B o r l a n d

E n t e r p r i s e

S e r v e r s

Cmp:

( B E S )

Secs

Indicates the time spent in the
CMP engine (excluding other
CMP tasks listed explicitly).
CmpInit:
Indicates
the
time
initializing
the
CMP
(startup cost only).

Secs
spent
engine

CmpQuery:

Secs

Indicates the time spent in the
CMP engine doing SQL queries.
CmpUpdate:

Secs

Indicates the time spent in the
CMP engine doing SQL updates
CmpGetConn:

Secs

Indicates the time spent in the
CMP
engine
getting
JDBC
connections (startup cost only).
CmpPrepareStmt:

Secs

Indicates the time spent in the
CMP
engine
preparing
statements (startup cost only).

14.3.2

Ejb Cont Stat Test

This test reports the time taken by the BES EJB container for performing various activities.

Purpose

Reports the time taken by the BES EJB container for performing various activities

Target of the
test

A BES server

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test

Outputs of the
test

One set of results for every BES partition monitored

466

M o n i t o r i n g

Measurements
made by the
test

B o r l a n d

E n t e r p r i s e

S e r v e r s

( B E S )

Measurement
Unit

Measurement
DispatchPOA:

Interpretation

Secs

Indicates the time spent on
receiving the TCP request, and
sending the reply.
DispatchHome:

Secs

Indicates the time spent in the
container dispatching methods
to EJBHome objects.
DispatchRemote:

Secs

Indicates the time spent in the
container dispatching methods
to EJBRemote objects.
DispatchBean:

Secs

Indicates the time spent in the
bean methods.
ResourceCommit:

Secs

Indicates
the
time
spent
specifically in committing the
work done on the resource (that
is, in committing to a database
such as Oracle)
Synchronization:
Indicates the
various
callbacks.

Secs

time spent in
Synchronization

LoadClass:

Secs

Indicates the time spent loading
classes from EJB Jars, etc.
(startup cost only).
ORBActivate:

Secs

Indicates the time spent in the
ORB, allocating objects from
pools
ORBDeactivate:

Secs

Indicates the time spent in the
ORB, releasing objects to pools

14.3.3

JDBC1 Test

This test reports the time taken by BES for performing JDBC1 related activities.

Purpose

Reports the time taken by BES for performing JDBC1 related activities

467

M o n i t o r i n g

B o r l a n d

E n t e r p r i s e

S e r v e r s

( B E S )

Target of the
test

A BES server

Agent
deploying the
test

An internal Agent

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

One set of results for every BES partition monitored

Measurement
Unit

Measurement
Jdbc1GetCon:

Interpretation

Secs

Indicates the time spent in the
Jdbc1 data source to get a
pooled connection.
Jdbc1NewCon:

Secs

Indicates the time spent in the
Jdbc1 datasource to get a new
connection (startup cost only).
Jdbc1RegRes:

Secs

Indicates the time spent in the
Jdbc1 datasource to register a
transaction
resource
in
transaction service.

14.3.4

JDBC2 Test

This test reports the time taken by BES for performing JDBC2 related activities.

Purpose

Reports the time taken by BES for performing JDBC2 related activities

Target of the
test

A BES server

Agent
deploying the
test

An internal Agent

468

M o n i t o r i n g

Configurable
parameters for
the test

B o r l a n d

E n t e r p r i s e

S e r v e r s

( B E S )

Outputs of the
test
Measurements
made by the
test

One set of results for every BES partition monitored

Measurement
Unit

Measurement
Jdbc2GetCon:

Interpretation

Secs

Indicates the time spent in the
Jdbc2 datasource to get a pooled
connection.
Jdbc2NewCon:

Secs

Indicates the time spent in the
Jdbc2 datasource to get a new
connection (startup cost only).
Jdbc2RegRes:

Secs

Indicates the time spent in the
Jdbc2 datasource to register a
transaction
resource
in
transaction service.
Jdbc2NewXaCon:

Secs

Indicates the time spent in the
Jdbc2 datasource to get a new
XA-enabled connection (startup
cost only)
Jdbc2XaStart:

Secs

Indicates the time spent in the
Jdbc2 datasource, starting a
transaction branch
Jdbc2XaEnd:

Secs

Indicates the time spent in the
Jdbc2 datasource to end a
transaction branch.

14.3.5

SFBeans Test

This test reports the time taken by the EJB container for passivating and activating stateful session
beans.

469

M o n i t o r i n g

B o r l a n d

E n t e r p r i s e

S e r v e r s

( B E S )

Purpose

Reports the time taken by the EJB container for passivating and activating stateful
session beans

Target of the
test

A BES server

Agent
deploying the
test

An internal Agent

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

One set of results for every BES partition monitored

Measurement
Unit

Measurement
Activation time:

Secs

Indicates the time spent in
activating a stateful session
bean.

470

Interpretation
If the EJB container spends more
time in passivating and activating
the bean instances, then try
increasing the timeout period for
EJBs. The default value is five
seconds. This property can be set
in the container properties file for
the Partition you are configuring.
This
file
is
located
at:
/var/servers//adm/properties/par
titions/(partitionname)/services/ejbcontainer.prop
erties. This file can be edited to
set
the
ejb.sfsb.passivation_timeout
property.

M o n i t o r i n g

B o r l a n d

E n t e r p r i s e

S e r v e r s

Passivation time:

( B E S )

Secs

Indicates
the
time
spent
passivating
stateful
session
beans.

14.3.6

If the EJB container spends more
time in passivating and activating
the bean instances, then try
increasing the timeout period for
EJBs. The default value is five
seconds. This property can be set
in the container properties file for
the Partition you are configuring.
This
file
is
located
at:
/var/servers//adm/properties/par
titions/(partitionname)/services/ejbcontainer.prop
erties. This file can be edited to
set
the
ejb.sfsb.passivation_timeout
property.

Transactions Test

This test reports the time taken by the EJB container for performing transaction related activities.

Purpose

Reports the time taken by the EJB container for performing transaction related
activities

Target of the
test

A BES server

Agent
deploying the
test

An internal Agent

Configurable
parameters for
the test

Outputs of the
test
Measurements
made by the
test

One set of results for every BES partition monitored

Measurement
Unit

Measurement
Begin transactions:
Indicates
the
time
beginning transactions.

Secs
spent

Commit transactions:
Indicates
the
time
beginning transactions.

Secs
spent

471

Interpretation

M o n i t o r i n g

B o r l a n d

E n t e r p r i s e

S e r v e r s

Rollback transactions:

Secs

Indicates the time spent rolling
back transactions

472

( B E S )

M o n i t o r i n g

J B o s s

A p p l i c a t i o n

S e r v e r s

Chapter

15
Monitoring JBoss Application
Servers
The JBoss Application Server is a widely used Java application server that provides a J2EE certified
platform for developing and deploying enterprise Java applications, web applications, and portals, and
also offers extended enterprise services such as clustering, caching, and persistence.
To monitor the JBoss application server, eG requires administrators to deploy two specialized
components on the target server. These components are, the eG MBean Service component, and the eG
Web Component.



eG MBean Service Component: This service is started by JBoss as soon as this component
is deployed to the server. The main purpose of this component is to get the MBean server
instance running on the JBoss server. It also provides static methods which use the MBean
server instance to gather relevant statistics from the JBoss server.



eG Web Component: This web component consists of one servlet. The eG agent will connect
to this servlet by passing relevant arguments. The servlet will then invoke the corresponding
static method of the MBean service component and return the result to the eG agent. The
agent will then compute the required metrics and upload the same the eG manager.

In order to enable the eG agents to extract statistics from the JBoss server, the above-mentioned
components need to be deployed on the JBoss server.
Once the components are deployed on the JBoss server, the eG agent periodically executes tests on
the server to capture the statistics collected by the components, and reports them to the eG manager.
These tests are mapped to specific layers of the JBoss application server's layer model (see Figure
15.1).

473

M o n i t o r i n g

J B o s s

A p p l i c a t i o n

S e r v e r s

Figure 15.1: The layer model of a JBoss application server

Note:
The JBoss monitoring model provided by eG Enterprise (see Figure 15.1) can be used to monitor a
JBoss server (versions 4.0 and 4.2.3), in an agent-based or an agentless manner.

The measures reported by the tests enable JBoss administrators to make accurate performance
judgments with respect to the following:
JVM heap monitoring

Request
Monitoring

processing

Thread pool monitoring

capability



How much memory has been allocated to the
JVM heap?



Is adequate free memory available in the JVM
heap?



Is the server
requests?



Are too many errors encountered by the server
during request processing?



Is the server overloaded with requests?



How many threads are currently busy? Does the
server appear to be handling too much load?

474

taking

too

long

process

M o n i t o r i n g

J B o s s

A p p l i c a t i o n

S e r v e r s



Are there adequate spare threads in the pool
for future processing requirements?



Does the thread pool require resizing?

Connection pool monitoring



Are enough connections available in the
connection pool, or do more connections have
to be allotted to the pool?

Servlet monitoring



How frequently was the servlet invoked?



Does the servlet take too long to execute?



How frequently are EJBs created/removed?



Are there any EJBs that are ready to service
clients?



How many EJBs are currently in the EJB pool?



Are too many messages have been enqueued?



How quickly does the queue process messages
within?



Does the topic
messages?



What type of messages are currently available
in the topic - durable or non-durable?



How many durable subscribers are there to a
topic?

EJB monitoring

Messaging service monitoring

Topic monitoring

take

too

long

process

The sections to come will indulge in an elaborate discussion of the top 6 layers of the layer model
depicted by Figure 15.1. As the other layers have been dealt with in great detail in the Monitoring Unix
and Windows Servers document, this chapter will not be discussing them again.

15.1

The JVM Layer

This layer collectively reports the resource usage and overall health of the JBoss JVM.

Figure 15.2: The tests mapped to the JVM layer
475

M o n i t o r i n g

J B o s s

A p p l i c a t i o n

S e r v e r s

All the tests displayed in Figure 15.2 have been dealt with in the previous chapters.

15.2 The JB Server Layer
The tests associated with the JB Server layer (see Figure 15.3) measure the request processing
capability of the JBoss server by monitoring critical parameters such as thread pool usage and
memory heap utilization.

Figure 15.3: The tests associated with the JB Server layer

15.2.1

Jboss JVM Test

This test monitors the heap usage and thread usage of the Java Virtual Machine (JVM) on which the
JBoss application server runs.

Purpose

Monitors the heap usage and thread usage of the Java Virtual Machine (JVM) on
which the JBoss application server runs

Target of the
test

A JBoss application server

Agent
deploying the
test

An internal agent

476

M o n i t o r i n g

Configurable
parameters for
the test

J B o s s

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT - The port number at which the specified HOST listens
4. MEASUREMENT MODE – This test can extract metrics from JBoss using either of
the following mechanisms:



By deploying the EgJBossAgent.sar and egjboss.war files on the target JBoss
server;



By contacting the Java runtime (JRE) of JBoss via JMX

To configure the test to use the EgJBossAgent.sar and egjboss.war files, first, select
the War File option. Then, refer to the Configuring and Monitoring Application
Servers document to know how to deploy these files on the target JBoss server.
On the other hand, if you want the test to use JMX instead, then first, select the
JMX option. Then, follow the procedure detailed in the Configuring and
Monitoring Application Servers document to configure the test to use JMX. By
default, the JMX option is chosen here.
5. JNDINAME – This parameter appears only if the MEASUREMENT MODE is set to
JMX. The JNDINAME is a lookup name for connecting to the JMX connector. By
default, this is jmxrmi. If you have registered the JMX connector in the RMI
registry using a different lookup name, then you can change this default value
to reflect the same.
6. JMX REMOTE PORT – This parameter appears only if the MEASUREMENT MODE
is set to JMX. Here, specify the port at which the JMX listens for requests from
remote hosts. Ensure that you specify the same port that you configured in the
management.properties file of the target JBoss server (refer to the Configuring
and Monitoring Application Servers document for more details).
7. JMX USER, JMX PASSWORD, and CONFIRM PASSWORD – These parameters
appear only if the MEASUREMENT MODE is set to JMX. If JMX requires
authentication only (but no security), then ensure that the JMX USER and JMX
PASSWORD parameters are configured with the credentials of a user with readwrite access to JMX. To know how to create this user, refer to the Configuring
and Monitoring Application Servers document. Confirm the password by retyping
it in the CONFIRM PASSWORD text box.
8. SSL - This parameter appears only if the MEASUREMENT MODE is set to War File.
Indicate Yes if the JBoss server is SSL-enabled.
9. URL - This parameter appears only if the MEASUREMENT MODE is set to War File.
Specify the URL to be accessed to collect metrics pertaining to the JBoss server.
By default, this test connects to a managed JBoss server and attempts to obtain
the metrics of interest by accessing the local Mbeans of the server. Accordingly,
by default, this parameter is set to http://:.

Outputs of the
test
Measurements
made by the

One set of results for every JBoss server monitored

Measurement

Measurement
Unit

477

Interpretation

M o n i t o r i n g

test

J B o s s

A p p l i c a t i o n

S e r v e r s

Free memory:

Indicates the memory available
in the JVM heap of the JBoss
application server.
Used memory:

Indicates the amount of JVM
heap memory used.
Total memory:

Indicates the total memory
allocated to the JVM.
Active threads:

Number

Indicates the total number of
threads that are currently active
in the JBoss server.

15.2.2

Jboss Server Test

This test monitors the requests handled by the JBoss server.

Purpose

Monitors the requests handled by the JBoss server

Target of the
test

A JBoss application server

Agent
deploying the
test

An internal agent

478

If
this
value
decreases
consistently, then try increasing
the memory heap of the JVM.

M o n i t o r i n g

Configurable
parameters for
the test

J B o s s

A p p l i c a t i o n

S e r v e r s



By deploying the EgJBossAgent.sar and egjboss.war files on the target JBoss
server;



By contacting the Java runtime (JRE) of JBoss via JMX

Outputs of the
test
Measurements
made by the

One set of results for every JBoss server monitored

Measurement

Measurement
Unit

479

Interpretation

M o n i t o r i n g

test

J B o s s

A p p l i c a t i o n

S e r v e r s

Request rate:

Reqs/Sec

With the advent of HTTP/1.1
multiple
requests
can
be
transmitted over the same TCP
connection. The ratio of requests
per connection can provide an
idea of the effectiveness of the
HTTP 1.1 protocol.

KB/Sec

A large increase in the data
transmission
rate
can
be
indicative of an increase in the
popularity of one or more web
sites hosted on the server.

KB/Sec

An increase in this value is
indicative of an increase in user
requests to the server.

MSecs

A high value may be an indication
of slow performance of the
server.

Indicates the rate of requests to
the server during the last
measurement period.

Data transmit rate:
Indicates the rate at which the
data was transmitted by the
server
during
the
last
measurement period.
Data received rate:
Indicates the rate at which data
was received by the server
during the last measurement
period.
Avg request processing time:
Indicates the average time taken
by the server to process
requests.
Max request processing time:

MSecs

Indicates the maximum time
taken by the server to process
requests.
Error rate:

Errors/Sec

Indicates the rate at which
errors were encountered by the
server in the last measurement
period.

15.2.3

Jboss Thread Pools Test

This test monitors the thread pools in the JBoss server.

Purpose

Monitors the thread pools in the JBoss server

Target of the
test

A JBoss application server

Agent
deploying the
test

An internal agent

480

M o n i t o r i n g

Configurable
parameters for
the test

J B o s s

A p p l i c a t i o n

S e r v e r s



By deploying the EgJBossAgent.sar and egjboss.war files on the target JBoss
server;



By contacting the Java runtime (JRE) of JBoss via JMX

Outputs of the
test
Measurements
made by the

One set of results for each thread pool configured in the JBoss server.

Measurement

Measurement
Unit

481

Interpretation

M o n i t o r i n g

test

J B o s s

A p p l i c a t i o n

S e r v e r s

Current busy threads:

Number

Indicates the number of threads
that are currently busy.
Current thread count:

The value of this measure serves
as a good indicator of server
workload.

Number

Indicates the number of threads
currently spawned in the JVM.
Min spare threads:

Number

Indicates the minimum number
of spare threads.
Max spare threads:

Number

Indicates the maximum number
of spare threads.
Max threads:

Number

Indicates the maximum number
of threads that this pool can
contain.

If the number of threads in a pool
grows close to the value of this
measure, it
indicates that the
number of threads in the pool
needs to be increased for
effective
operation
of
this
application. Alternatively, you
may also consider changing the
maximum number of threads that
a pool can contain. However,
exercise caution when altering
the maximum thread count, as a
very high thread count can cause
the app to slowdown from
excessive
memory
usage.
Likewise, if the maximum thread
count is set too low, it will cause
requests to block or timeout.

15.3 The JB Connection Pool Layer
This layer of the JBoss application server monitors the connection pools configured in the JBoss
application server, and indicates whether the pools have been adequately sized and are being
effectively utilized.

482

M o n i t o r i n g

J B o s s

A p p l i c a t i o n

S e r v e r s

Figure 15.4: The test associated with the JB Connection Pool layer

15.3.1

Jboss Connection Pools Test

This test monitors the various connection pools configured in the JBoss server, and reveals how well
the pools have been used.

Purpose

Monitors the various connection pools configured in the JBoss server, and reveals
how well the pools have been used

Target of the
test

A JBoss application server

Agent
deploying the
test

An internal agent

483

M o n i t o r i n g

Configurable
parameters for
the test

J B o s s

A p p l i c a t i o n

S e r v e r s



By deploying the EgJBossAgent.sar and egjboss.war files on the target JBoss
server;



By contacting the Java runtime (JRE) of JBoss via JMX

Outputs of the
test
Measurements
made by the

One set of results for each connection pool configured in the JBoss server.

Measurement

Measurement
Unit

484

Interpretation

M o n i t o r i n g

test

J B o s s

A p p l i c a t i o n

S e r v e r s

Connections created:

Number

Indicates the total number of
connections created since the
start of the connection pool.
Current connections:
Indicates
the
number
connections currently in
pool.

Number
of
the

Connections in use:

Number

Indicates the number of
connections that are currently in
use.
Connections destroyed:

If the value of this measure
reaches
that
of
the
Curr_conn_count measure, then
it indicates that the pool requires
resizing.

Number

Indicates
the
number
of
connections that were destroyed
since the start of the server.
Max connections in use:

Number

Indicates the high water mark of
the connections in use count.
Available connections:

Number

Ideally, this value should be high.

Indicates
the
number
of
connections that are currently
available in the pool for clients to
use.
Min connection size:

Number

Indicates the minimum value of
the number of connections in the
pool since the start of the pool.
Max connection size:

Number

Indicates the maximum value of
the number of connections in the
pool since the start of the pool.

15.4 The JB Servlet Layer
The JB Servlet layer executes the JbossServlets test (see Figure 15.5) that monitors the performance of
the servlets deployed on the JBoss application server.

485

M o n i t o r i n g

J B o s s

A p p l i c a t i o n

S e r v e r s

Figure 15.5: The test associated with the JB Servlet layer

15.4.1

Jboss Servlets Test

This test monitors the servlets deployed on the JBoss server. If the JBoss server hosts a large number
of servlets, then managing the individual servlets would be quiet a challenge. Therefore, to enable
administrators to manage servlets easily, the eG Enterprise system allows the configuration of servlet
groups. The eG agent executing this test will then, by default, report measures for every group that is
configured. To configure servlet groups, click on the Click here hyperlink in the test configuration page
of the JbServletTest.

Purpose

Monitors the servlets deployed on the JBoss server

Target of the
test

A JBoss application server

Agent
deploying the
test

An internal agent

486

M o n i t o r i n g

Configurable
parameters for
the test

J B o s s

A p p l i c a t i o n

S e r v e r s



By deploying the EgJBossAgent.sar and egjboss.war files on the target JBoss
server;



By contacting the Java runtime (JRE) of JBoss via JMX

Outputs of the
test
Measurements
made by the

By default, the test reports one set of results for each servlet group that is
configured using the eG administrative interface.

Measurement

Measurement
Unit

487

Interpretation

M o n i t o r i n g

test

J B o s s

A p p l i c a t i o n

S e r v e r s

Invocation rate:
Indicates the number of times
the servlet was invoked per
second in the last measurement
period.
Avg invocation time:

Invocations/
Sec

This is indicative of the load on a
servlet.

Msecs

Indicates the average time taken
to execute a servlet.
Max invocation time:

Msecs

Indicates the maximum time
taken to execute a servlet.

15.5 The JB EJB Layer
The JB EJB layer executes the JbossEjbs test (see Figure 15.6), which evaluates the performance of the
Enterprise Java Beans (EJBs) deployed on the JBoss application server.

Figure 15.6: The test associated with the JB EJB layer

15.5.1

Jboss Ejbs Test

This test monitors the EJBs deployed on the JBoss server. If the JBoss server hosts a large number of
EJBs, then managing the individual EJBs would be quiet a challenge. Therefore, to enable
administrators to manage EJBs easily, the eG Enterprise system allows the configuration of EJB
groups. The eG agent executing this test will then, by default, report measures for every group that is
configured. To configure EJB groups, click on the Click here hyperlink in the test configuration page of
the JbEjbTest.

Purpose

Monitors the EJBs deployed on the JBoss server

Target of the
test

A JBoss application server

488

M o n i t o r i n g

J B o s s

A p p l i c a t i o n

S e r v e r s

Agent
deploying the
test

An internal agent

Configurable
parameters for
the test



By deploying the EgJBossAgent.sar and egjboss.war files on the target JBoss
server;



By contacting the Java runtime (JRE) of JBoss via JMX

Outputs of the
test
Measurements
made by the

By default, the test reports one set of results for each EJB group that is configured
using the eG administrative interface.

Measurement

Measurement
Unit
489

Interpretation

M o n i t o r i n g

test

J B o s s

A p p l i c a t i o n

S e r v e r s

Creation rate:

EJBs/Sec

Indicates the rate of creation of
beans.
Removal rate:

EJBs/Sec

Indicates the rate at which the
EJBs are removed.
Message rate:

Msgs/Sec

Indicates the rate at which
messages are handled.
Method ready count:

Number

Indicates the number of EJBs
where the methods are currently
in the ready state to service
clients. A Method is a function
invoked by clients on the EJB to
perform a specific task.
Ready count:

Number

Indicates the number of EJBs
that are currently ready to
service clients.
Pooled count:

Number

Indicates the number of EJBs
that are in the pool, currently.
Passive count:

Number

Indicates the number of EJB
instances
that
have
been
passivated,
currently.
Passivation is the act of storing
an EJB instance in a permanent
store like a hard disk for future
activation.

15.6 The JB MQ Layer
The tests associated with the JB MQ layer (see Figure 15.7) monitor the messaging service of the JBoss
application server.

490

M o n i t o r i n g

J B o s s

A p p l i c a t i o n

S e r v e r s

Figure 15.7: The tests associated with the JB MQ layer
The JMS API stands for Java Message Service Application Programming Interface, and is used by the
JBoss server to send asynchronous business-quality messages to other applications. In the messaging
world, messages are not sent directly to other applications. Instead, messages are sent to
destinations. A destination is the object on the JBossMQ server that clients use to send and receive
messages. There are two types of destination objects, namely, Queues and Topics. The
JbossMQQueues test and the JbossMQTopics test mapped to the JB MQ layer monitor each of the abovementioned destination objects, respectively.

15.6.1

Jboss MQ Queues Test

This test monitors the queues on the JBoss server. Clients that are in the point-to-point paradigm
typically use queues. They expect that message sent to a queue will be received by only one other
client once and only once. If multiple clients are receiving messages from a single queue, the
messages will be load balanced across the receivers. Queue objects, by default, will be stored under
the JNDI queue/ sub context.

Purpose

Monitors the queues on the JBoss server

Target of the
test

A JBoss application server

Agent
deploying the
test

An internal agent

491

M o n i t o r i n g

Configurable
parameters for
the test

J B o s s

A p p l i c a t i o n

S e r v e r s



By deploying the EgJBossAgent.sar and egjboss.war files on the target JBoss
server;



By contacting the Java runtime (JRE) of JBoss via JMX

492

M o n i t o r i n g

J B o s s

A p p l i c a t i o n

S e r v e r s

11. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG
system embeds an optional detailed diagnostic capability. With this capability,
the eG agents can be configured to run detailed, more elaborate tests as and
when specific problems are detected. To enable the detailed diagnosis capability
of this test for a particular server, choose the On option against DETAILED
DIAGNOSIS. To disable the capability, click on the Off option.

Outputs of the
test
Measurements
made by the
test

One set of results for every queue on the JBoss application server

Measurement
Unit

Measurement
Max queue depth:

Interpretation

Number

Indicates the max value of the
number of messages that were
in this queue since the start of
the queue.
Message processing rate:

Msgs/Sec

Indicates the rate at which
messages are being processed
by this queue.
Receivers count:

Msgs/Sec

Indicates the number of clients
that are currently configured as
receivers of messages from this
queue.
Current queue depth:
Indicates
messages
queue.

the
number
currently
in

Number
of
this

Use the detailed diagnosis of this
measure to know the JMS ID,
Priority, Time, ProducerID, and
the contents of each Message in
the queue.

Scheduled messages count:

Number

Use the detailed diagnosis of this
measure to know the JMS ID,
Priority, Time, ProducerID, and
the contents of each Message
that is scheduled for delivery.

Percent

A high value is a cause for
concern as it could indicate a
bottleneck in message delivery,
which may be heavily populating
the queue with messages.

Number

A high value is desired for this
measure.

Indicates
the
number
of
messages in this queue that are
currently
scheduled
to
be
delivered.
Queue occupied:
Indicates the percentage of
queue length that is occupied by
messages.
Message delivered:

A high value is indicative of
server workload, or a delivery
bottleneck.

Indicates the number of
messages in this queue that
have been delivered.

493

M o n i t o r i n g

J B o s s

A p p l i c a t i o n

S e r v e r s

Messages added:

Number

Indicates the number of
messages that were added to
this queue during the last
measurement period.
Last message sent time:

Secs

Ideally, the value of this measure
should be low. A high value is
indicative of a delay in message
delivery or a message processing
bottleneck.

Number

Use the detailed diagnosis of this
measure to view the ID of all the
subscribers registered with the
queue.

Number

Use the detailed diagnosis of this
measure to view the ID of all the
receivers configured for this
queue.

Indicates the time that elapsed
since the last message was sent
from this queue.
Subscriber count:
Indicates the number of
subscribers who are registered
with this queue.
Receivers count:
Indicates the number of clients
that are currently configured as
receivers of messages from this
queue.

15.6.2

Jboss MQ Topics Test

The JbossMQTopics test monitors the topics on the JBoss server. Topics are used in the publishsubscribe paradigm. When a client publishes a message to a topic, he expects that a copy of the
message will be delivered to each client that has subscribed to the topic. However, if the client is not
up, running and receiving messages from the topics, it will miss messages published to the topic. To
get around this problem of missing messages, clients can start a durable subscription. This is like
having a VCR record a show you cannot watch at its scheduled time so that you can see what you
missed when you turn your TV back on. Similarly, messages meant for a durable subscriber are stored
in the persistent cache even when the subscriber is inactive. These messages are delivered to durable
subscribers when they connect to the server.

Purpose

Monitors the topics on the JBoss server

Target of the
test

A JBoss application server

Agent
deploying the
test

An internal agent

494

M o n i t o r i n g

Configurable
parameters for
the test

J B o s s

A p p l i c a t i o n

S e r v e r s



By deploying the EgJBossAgent.sar and egjboss.war files on the target JBoss
server;



By contacting the Java runtime (JRE) of JBoss via JMX

Outputs of the
test
Measurements
made by the

One set of results for every topic on the JBoss application server

Measurement

Measurement
Unit

495

Interpretation

M o n i t o r i n g

test

J B o s s

A p p l i c a t i o n

S e r v e r s

Max topic depth:

Number

Indicates the max value of the
number of messages in the topic
since the start of the queue.
Msg process rate:

Msgs/Sec

Indicates the rate at which
messages were being processed
by the topic in the last
measurement period.
Durable messages count:

Number

Indicates the number of durable
messages currently in the topic.
Non-durable messages count:

Number

Indicates the number of nondurable messages currently in
the topic.
Total subjects count:

Number

Indicates the total number of
subscribers to a topic.
Durable subjects count:

Number

Indicates the number of durable
subscribers to the topic.

Non-durable subjects count:

Number

Indicates
the
number
of
subscribers to the topic who are
currently non-durable.

496

If the total number of durable
subscribers is high, then we can
expect
the
total
durable
messages to be stored on the
server also to be relatively on the
higher side.

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

Chapter

16
Monitoring Domino Application
Servers
The Lotus Domino server is an open, secure platform optimized to deliver messaging, applications,
and online collaboration that integrates your enterprise systems with dynamic business processes.
Used by small and large enterprises alike, the Domino server helps harness the power of the web to
facilitate rapid application development, provides an efficient messaging mechanism, and also aids in
securing IT environments from unauthorized access.
Owing to its wide usage and the crucial role it plays in the development, delivery, and security of
business-critical services, even a semblance of a problem in the functioning of the Domino application
server could be perilious to the health, availability, and reliability of a service offering. To avoid such
adversities, it is necessary to keep a constant eye on the performance-impacting activities of the
Domino application server, so that issues come to light early and are addressed quickly.
eG Enterprise has developed an exclusive Domino application monitoring model (see Figure 16.6) for
the Domino application server, which employs an eG agent to continuously monitor the performance
of the server. This eG agent executes tests which communicate with the Domino SNMP agent to collect
key metrics relating to server performance. To facilitate this communication, SNMP should be enabled
on the application server.

16.1 Enabling SNMP on a Domino Server
Domino SNMP Agent services are provided by two types of programs:



LNSNMP -- The Lotus Notes SNMP agent. As an independent application, LNSNMP is insulated
from most Domino server malfunctions and, by itself, adds negligible overhead to the server.



Two Domino server add-ins -- the QuerySet Handler and the Event Interceptor.
The QuerySet Handler and the Event Interceptor depend on the Domino server; if the server
fails for any reason, these programs fail as well.

The following components comprise the Domino SNMP Agent architecture:



A platform-specific Master SNMP Agent -- An independent, non-Lotus, agent usually
supplied with the operating system platform that provides SNMP services for the machine. This
SNMP Agent transports the SNMP traps and Get/Set responses across the network to the
management station.



The Domino SNMP Agent consisting of:
497

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

LNSNMP Agent -- The Lotus Notes SNMP agent, which receives trap notifications
from the Event Interceptor and then forwards them to the management station
using the platform-specific SNMP Agent. LNSNMP also handles requests for
Domino-related information from the management station by passing the request
to the QuerySet Handler and responding back to the management station.

QuerySet Handler -- Which queries server statistics information, sets the value of
configurable Domino-based parameters, and returns Domino statistics information
to LNSNMP, which then forwards the information to the management station using
the platform-specific master SNMP Agent.

Event Interceptor -- Which responds to the SNMP Trap notification for Domino
Event Handlers by instructing LNSNMP to issue a trap.

The Domino MIB -- A standard Management Information Base (MIB) file for Lotus Domino
servers that can be compiled and used by a network management program such as eG
Enterprise.



16.1.1

Enabling SNMP for a Domino Server on Solaris

To enable SNMP on a Domino server on Solaris, follow the broad steps given below:



Install the Master SNMP agent on the Domino server



Configure the Domino SNMP agent to communicate with the Master SNMP agent

Each of these steps has been discussed in great detail below.

16.1.1.1 Installing and Configuring the Master SNMP Agent on the
Domino Server
On Solaris platform, the Domino SNMP Agent uses the SMUX protocol, per RFC 1227, to communicate
with the system's Master SNMP Agent. The Solaris Master SNMP Agent does not support the SMUX
protocol, making it necessary to substitute a Master SNMP Agent that does. On Solaris platforms,
Domino includes a suitable NET-SNMP Master Agent, called NET-SNMPD, already configured to support
the SMUX protocol and the Domino SNMP Agent.

Note:
Before using NET-SNMPD, disable any existing Master SNMP Agent. Please follow the steps
below for disabling an existing Master SNMP Agent running on Solaris.



Stop the snmpdx daemon by typing, /etc/rc3.d/S76snmpdx stop.



Disable

the snmpdx daemon
/etc/rc3.d/s76snmpdx.

issuing

the

command,

mv /etc/rc3.d/S76snmpdx

To use the NET-SNMPD that is provided with Domino, do the following:
1. Login as the root user.
2. Next, install the NET-SNMPD files. Enter this command, changing the Domino executable path if
necessary: cp /opt/lotus/notes/latest/sunspa/net-snmpd* /etc
498

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

3. Arrange for NET-SNMPD to be restarted after a reboot. Enter these commands:

ln -f -s /etc/net-snmpd.sh /etc/init.d/net-snmpd
ln -f -s /etc/init.d/net-snmpd /etc/rc2.d/S76net-snmpd
ln -f -s /etc/init.d/net-snmpd /etc/rc1.d/K76net-snmpd
4. After installation, proceed to configure and start NET-SNMPD. Here is how:
5. Udate the /etc/net-snmpd.conf file with appropriate community names for your remote management
infrastructure. Community names are set using the rocommunity and rwcommunity directives. For
instance, to set a community named nppublic, the command would be: Set rocommunity value to

nppublic
6. To manually start NET-SNMPD, login as the root user and issue the command, /etc/net-snmpd.sh
start. To stop NET-SNMPD, use this command: /etc/net-snmpd.sh stop

16.1.1.2

Configuring the Domino SNMP Agent

The Domino SNMP Agent configuration on Solaris involves the following:



Configuring the LNSNMP agent to work with the Master SNMP Agent that is provided with the
Domino server on Solaris



Completing the configuration by starting the add-in tasks

Before attempting to configure the Domino SNMP agent, ensure the following:



The Solaris Master SNMP Agent provided with Domino should be properly installed and
configured on the server. Refer to the steps discussed in Section 16.1.1.1 for the procedure.



TCP/IP and SNMP should be properly installed and configured on the server. Ensure that the
Domino executable and the Domino data directories are in your search path.



The Domino SNMP Agent is set up to run automatically. Once the Domino SNMP Agent is
configured, it is virtually always running, even when Domino is not. If you later upgrade
Domino, stop the LNSNMP process, before beginning the upgrade process.

To configure the LNSNMP agent, do the following:
1. Login as the root-user.
2. Stop the LNSNMP process. Enter this command: lnsnmp.sh stop
3. Stop the NET-SNMP Master Agent by entering this command: /etc/net-snmpd.sh stop
4. Start the NET-SNMP Master Agent by entering this command: /etc/net-snmpd.sh start
5. Start the LNSNMP process using the command, lnsnmp.sh start
6. Create a link to the LNSNMP script. Enter this command, changing the Domino executable path if
necessary: ln -f -s /opt/lotus/notes/latest/sunspa/lnsnmp.sh /etc/init.d/lnsnmp
7. Arrange for LNSNMP to be restarted after a reboot. Enter these commands:

ln -f -s /etc/init.d/lnsnmp /etc/rc2.d/S77lnsnmp
ln -f -s /etc/init.d/lnsnmp /etc/rc1.d/K77lnsnmp

499

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

After configuring the LNSNMP agent, start the Domino server add-in tasks such as the QuerySet,
Event Interceptor, and Statistic Collector tasks. To achieve this, do the following:
1. To support SNMP queries, start the QuerySet add-in task. Enter this command on the Domino
Server console: load quryset
2. To support SNMP traps for Domino events, start the Event Interceptor add-in task. Enter this
command on the Domino Server console: load intrcpt
3. To support Domino statistic threshold traps, start the Statistic Collector add-in task. Enter this
command on the Domino Server console: load collect
4. Arrange for the add-in tasks to be restarted automatically when Domino is next restarted. Add
quryset and/or intrcpt and collect to the ServerTasks variable in Domino’s notes.ini file.

ServerTasks =Update,Replica,Router,Amgr,AdminP,CalConn,Sched,LDAP,quryset,intrcpt,collect

16.1.2

Enabling SNMP for a Domino Server on Linux

To enable SNMP on a Domino server on Linux, follow the broad steps given below:



Install the Master SNMP agent on the Domino server



Configure the Domino SNMP agent to communicate with the Master SNMP agent

Each of these steps has been discussed in great detail below.

16.1.2.1 Installing and Configuring the Master SNMP Agent on the
Domino Server
Like the Solaris platform, on Linux also the Domino SNMP Agent uses the SMUX protocol, per RFC
1227, to communicate with the system's Master SNMP Agent. Some Linux distributions include a
Master SNMP Agent that supports the SMUX protocol; others do not. On Linux platforms, Domino
includes a suitable NET-SNMP Master Agent, called NET-SNMPD, already configured to support the
SMUX protocol and the Domino SNMP Agent.
Note:
Before using NET-SNMPD, disable any existing MasterSNMP Agent. For information on disabling
an existing Master SNMP Agent, see your Master SNMP Agent's documentation.

ln -f -s /etc/net-snmpd.sh /etc/rc.d/init.d/net-snmpd
chkconfig --add net-snmpd
chkconfig net-snmpd on
500

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

4. After installation, proceed to configure and start NET-SNMPD. Here is how:
5. Udate the /etc/net-snmpd.conf file with appropriate community names for your remote management
infrastructure. Community names are set using the rocommunity and rwcommunity directives. For
instance, to set a community named nppublic, the command would be, Set rocommunity value to
nppublic.
6. To manually start NET-SNMPD, login as the root user and issue the command, /etc/net-snmpd.sh
start. To stop NET-SNMPD, use the command, /etc/net-snmpd.sh stop.

16.1.2.2

Configuring the Domino SNMP Agent

The Domino SNMP Agent configuration on Linux involves the following:



Configuring the LNSNMP agent to work with the Master SNMP Agent that is provided with
Domino on Linux



Completing the configuration by starting the add-in tasks

Before attempting to configure the Domino SNMP agent, ensure the following:



The Linux Master SNMP Agent provided with Domino should be properly installed and
configured on the server. Refer to the steps discussed in Section 16.1.1.1 for the procedure.



TCP/IP and SNMP should be properly installed and configured on the server. Ensure that the
Domino executable and the Domino data directories are in your search path.



To configure the LNSNMP agent, do the following:
1. Login as the root-user.
2. Stop the LNSNMP process. Enter this command: lnsnmp.sh stop
3. Stop the NET-SNMP Master Agent by entering this command: /etc/net-snmpd.sh stop
4. Start the NET-SNMP Master Agent by entering this command: /etc/net-snmpd.sh start
5. Start the LNSNMP process using the command, lnsnmp.sh start.
6. Arrange for LNSNMP to be restarted after a reboot. Enter these commands:

ln -f -s /opt/lotus/notes/latest/linux/lnsnmp.sh /etc/rc.d/init.d/lnsnmp
chkconfig --add lnsnmp
chkconfig lnsnmp on
After configuring the LNSNMP agent, start the Domino server add-in tasks such as the QuerySet,
Event Interceptor, and Statistic Collector tasks. To achieve this, do the following:
1. To support SNMP queries, start the QuerySet add-in task. Enter this command on the Domino
Server console: load quryset

501

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

2. To support SNMP traps for Domino events, start the Event Interceptor add-in task. Enter this
command on the Domino Server console: load intrcpt
3. To support Domino statistic threshold traps, start the Statistic Collector add-in task. Enter this
command on the Domino Server console: load collect
4. Arrange for the add-in tasks to be restarted automatically when Domino is next restarted. Add
quryset and/or intrcpt and collect to the ServerTasks variable in Domino’s notes.ini file.

ServerTasks =Update,Replica,Router,Amgr,AdminP,CalConn,Sched,LDAP,quryset,intrcpt,collect

16.1.3

Enabling SNMP for a Domino Server on AIX

To enable SNMP on an AIX Domino server, you will have to configure the Domino SNMP agent. This
involves ensuring that the LNSNMP process communicates with the SNMPD subsystem (on the AIX
installation of Domino) using the SMUX protocol.
However, prior to configuring the Domino SNMP agent, make sure that the following are in place:



TCP/IP and SNMP should be properly installed and configured on the server. Also, make sure
that the Domino executable and the Domino data directories are in your search path



The trap destinations and community names for AIX should be appropriately configured in the
/etc/snmpd.conf file for your remote management infrastructure. Remember to keep the view
identifiers unique for each trap destination.



The Domino SNMP Agent is set up to run automatically. This means that once the Domino
SNMP Agent is configured, it is virtually always running, even when Domino is not. If you later
upgrade Domino you should stop the LNSNMP process before beginning the upgrade process.

Next, proceed to configure the Domino SNMP agent, using the procedure explained below:
1. Login as the root user.
2. Stop the LNSNMP process. Enter this command: lnsnmp.sh stop
3. Stop the SNMPD (SNMP Daemon) subsystem. The Simple Network Management Protocol (SNMP)
daemon is a background server process that can be run on any Transmission Control
Protocol/Internet Protocol (TCP/IP) workstation host. The daemon, acting as SNMP agent,
receives, authenticates, and processes SNMP requests from manager applications. This daemon is
installed and started by default on AIX systems. To stop SNMPD, e nter this command: stopsrc -s

snmpd
4. Configure SNMPD to accept LNSNMP as an SMUX peer. Add the following line to the
/etc/snmpd.peers file: "Lotus Notes Agent" 1.3.6.1.4.1.334.72 "NotesPasswd"
5. Configure SNMPD to accept an SMUX association from LNSNMP. Add the following line to
/etc/snmpd.conf: smux 1.3.6.1.4.1.334.72 NotesPasswd
6. Start the SNMPD subsystem. Enter this command: startsrc -s snmpd
7. Start the LNSNMP process. Enter this command: lnsnmp.sh start
8. Create a link to the LNSNMP script. Enter this command, changing the Domino executable path if
necessary: ln -f -s /opt/lotus/notes/latest/ibmpow/lnsnmp.sh /etc/lnsnmp.rc
9. Arrange for LNSNMP to be restarted after a reboot. Add the following line to the end of the
/etc/rc.tcpip file: /etc/lnsnmp.rc start

502

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

After configuring the LNSNMP agent, start the Domino server add-in tasks such as the QuerySet,
Event Interceptor, and Statistic Collector tasks, using the procedure discussed in Section 16.1.2.2.

16.1.4

Enabling SNMP for a Domino Server on Windows

To enable SNMP on a Windows Domino server, follow the broad steps given below:



Install the Windows SNMP service on the target host



Install the LNSNMP agent (i.e., the Lotus Domino SNMP agent) on the target host



Configure the Lotus Domino SNMP agent as a service on the target host

Each of these steps is discussed in great detail in the sections to come.

16.1.4.1

Installing the Windows SNMP Service

To install the SNMP service on Windows 2000, do the following:
1. Login to the Windows 2000 system as an administrator.
2. Click on the Start button on the taskbar, and follow the menu sequence: Settings -> Control Panel.
3. Double-click on the Add/Remove Programs option in the Control Panel window (see Figure 16.1).

Figure 16.1: The Add/Remove Programs option in the Control Panel window
4. Next, select the Add/Remove Windows Components option from the Add/Remove Programs dialog box
(see Figure 16.2).

503

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

Figure 16.2: Select the Add/Remove Windows Components option
5. Then, a list of windows components that can be added will appear. Select the Management and
Monitoring Tools option from this list, and click the Details button to view more details about it (see
Figure 16.3).

Figure 16.3: Selecting the Management and Monitoring Tools option
6. From the list that appears next, select the Simple Network Management Protocol (SNMP) option to add
it. Then, click the OK button (see Figure 16.4).

504

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

Figure 16.4: Selecting the SNMP option
7. You will then return to Figure 16.3. Click the Next button here to proceed with installing the SNMP
service.
8. If you are prompted for the path to the Windows 2000 installation CD, provide the correct path,
and click on the OK button to begin installing the SNMP service (see Figure 16.5).

Figure 16.5: Providing the path to the Windows 2000 CD

16.1.4.2

Installing the LNSNMP Agent

To install the LNSNMP agent, do the following:
1. Run the nvinst.exe executable that is available in the /w32intel folder.
2. Once execution begins, setup will prompt you to choose one of the following options:
Domino Management Agent for Windows NT installation.
Copyright (c) 1994-1999, Lotus Development Corporation.
Lotus Domino Management Agent Install (Version 5.0)
Installation Options
--------------------------------------------------1)
2)
3)
Q)

Install Domino SNMP Agent Software
Install Domino Mail Reflector Software
Install Both Options 1 and 2
Quit Installation
505

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

Choice (1/2/3/Q): 1
3. To install the LNSNMP agent, enter 1 as the Choice.
4. Setup will then request your confirmation for adding the Collector task. Enter y to add the task.
The "Collector" task is not currently configured to run on this system. This task
is necessary if you want Notes to generate events based on statistics thresholds.
Do you want to add this task now? (y/n): y
5. Once the LNSNMP agent installation completes, the following message will appear:
Domino Management Agent successfully installed.
Please reboot the system for the changes to take effect.
D:\Lotus\Domino\w32intel>
After Rebooting start the LNSNMP Service first
And then start the Domino Server.

16.1.4.3

Configuring the LNSNMP Agent

Prior to configuring the LNSNMP agent, ensure the following:



Before using the Domino SNMP Agent, make sure TCP/IP and SNMP are properly installed and
configured on the server. Also, make sure that the Domino executable and the Domino data
directories are in your search path.



If you need to add the Windows SNMP Service to your system, be prepared to reinstall any
Windows service packs immediately after adding the Windows SNMP Service.



The Windows SNMP Service is configured by double-clicking the Network icon in the Control
Panel, then selecting the Services tab, then selecting SNMP Service, and then clicking the
Properties button. You will want to configure appropriate trap destinations and community
names for your remote management infrastructure.



The Domino SNMP Agent is configured as a Windows Service and is set up to run
automatically. This means that once the Domino SNMP Agent is configured, it is virtually
always running, even when Domino is not. If you later upgrade Domino you should stop the
LNSNMP and Windows SNMP Services before beginning the upgrade process.

To configure the LNSNMP agent, do the following:
1. Stop the LNSNMP and SNMP services. Enter these commands:

net stop lnsnmp
net stop snmp
2. Configure the Lotus Domino SNMP Agent as a service. Enter this command: lnsnmp -Sc
3. Start the SNMP and LNSNMP services. Enter these commands:

net start snmp
net start lnsnmp

506

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

After configuring the LNSNMP agent, start the Domino server add-in tasks such as the QuerySet,
Event Interceptor, and Statistic Collector tasks, using the procedure discussed in Section 16.1.2.2
Once the Domino SNMP agent is completely configured, the tests executed by the eG agent (which is
monitoring the Domino server's performance), polls the SNMP agent at frequent intervals for
performance data. The SNMP agent then retrieves the desired performance statistics from the SNMP
MIB of the Domino server and forwards the same to the eG agent.
Using these statistics, administrators can easily and accurately answer the following performance
queries:



Has the Domino server's capacity been fully utilized? If not, what percentage of its capacity is
still available for request processing?



Are sufficient threads available for handling requests to the Domino server?



Are there too many concurrent connection requests to the server?



Has enough memory been allocated to the Domino processes and shared memory segments?



Are the NSF buffer pools and buffer control pools adequately sized on the Domino database?



Are hits to the database cache optimal, or does the cache require any resizing?



How many databases are currently awaiting replication and for how long have they been
waiting? Were too many databases in the queue for too long? If so, can additional replicators
be configured to share the load?



Has the cluster replicator successfully handled all replication requests to it, or have too many
requests failed?



What is the current load on the web server component of the application server? Is it too
heavy?



Is the idle session count kept at a minimum?

The tests that reveal the above are mapped to the various layers of the monitoring model of Figure
16.6.

Figure 16.6: Layer model of the Domino application server
The section that follows discusses the first layer of Figure 16.6 and the tests that are mapped to it.
While the next 2 layers have been dealt with extensively in the Monitoring Mail Servers document, the
remaining layers have been elaborately discussed in the Monitoring Unix and Windows Servers
document.

507

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

16.2 The Domino Service Layer
The critical services provided by the Domino server are monitored by the tests associated with the
Domino Service layer. These include:



Servicing the web requests to its web server component



Servicing the database replication requests to servers in a cluster

Figure 16.7: The tests associated with the Domino Service Layer

16.2.1

Lotus Notes Web Server Test

This test reports the web server statistics of a Lotus Domino server.

Purpose

Reports the web server statistics of a Lotus Domino server

Target of the
test

A Domino application server

Agent
deploying the
test

An internal/remote agent

508

M o n i t o r i n g

Configurable
parameters for
the test

D o m i n o

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT - The port number at which the specified HOST listens
4. SNMPPORT - The port number through which the server exposes its SNMP MIB.
The default value is 161.
5. SNMPVERSION – By default, the eG agent supports SNMP version 1. Accordingly,
the default selection in the SNMPVERSION list is v1. However, if a different SNMP
framework is in use in your environment, say SNMP v2 or v3, then select the
corresponding option from this list.
6. SNMPCOMMUNITY – The SNMP community name that the test uses to
communicate with the target server. The default is public. This parameter is
specific to SNMP v1 and v2 only. Therefore, if the SNMPVERSION chosen is v3,
then this parameter will not appear.
7. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
8. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
9. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
10. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

13. ENCRYPTPASSWORD – Specify the encryption password here.
14. CONFIRM PASSWORD – Confirm the encryption password by retyping it here.

509

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

15. TIMEOUT - Specify the duration (in seconds) within which the SNMP query
executed by this test should time out in the TIMEOUT text box. The default is 10
seconds.

Outputs of the
test
Measurements
made by the
test

One set of results for the Domino application server that is monitored

Measurement
Unit

Measurement
Request rate:

Reqs/Sec

Indicates the number of requests
handled by the web server
during the last measurement
period.
HTTP connections:

Interpretation
A high value is indicative of heavy
work load on the server.

Conns/Sec

Indicates the number of HTTP
connections accepted during the
last measurement period.
Current connections:

Number

Indicates the number of current
HTTP connections.
Data received rate:

Kbytes/Sec

Indicates the amount of data
received by the web server
during the last measurement
period.
Data sent rate:

Kbytes/Sec

Indicates the amount of data
sent by the web server during
the last measurement period.
Http workers:

Number

Indicates the number of HTTP
worker
processes
currently
servicing web server requests.
Idle session timeouts:

Number

Indicates the number of idle
sessions timed out during the
last measurement period.

510

Idle sessions might waste server
resources. If the load on a server
is very high and idle sessions are
also quiet a few, you may want to
reduce the idle session timeout
value so that idle sessions get
timed out more often. This way
the strain on the server is greatly
reduced, and server resources are
preserved.

M o n i t o r i n g

16.2.2

D o m i n o

A p p l i c a t i o n

S e r v e r s

Lotus Notes Replication Test

A Domino cluster is a group of two or more servers that provides users with constant access to data,
balances the workload between servers, improves server performance, and maintains performance
when you increase the size of your enterprise. The servers in a cluster contain replicas of databases
that you want to be readily available to users at all times. If a user tries to access a database on a
cluster server that is not available, Domino opens a replica of that database on a different cluster
server, if a replica is available. Domino continuously synchronizes databases so that whichever replica
a user opens, the information is always the same.
There is a special component on the servers in a cluster, called "Cluster Replicator" that is responsible
for replication being performed between the databases. When a cluster replicator learns of a change to
a database, it immediately pushes that change to all other replicas in the cluster. All replication events
are stored in memory, and if a destination server is not available, the "Cluster Replicator" continues to
store these events in memory until the destination server bevomes available.
By default, every server in a cluster consists of a single cluster replicator. However, in order to
augment the performance of the Domino cluster, multiple replicators can be configured on a server.
The decision to introduce more replicators on a cluster server can be taken only after understanding
and analyzing how well the default replicator on the server handles the replication requests to it. The
LnReplication test periodically monitors a cluster server's replicator-related activities and reveals
critical performance statistics based on which administrators can decide whether/not to add more
replicators to it.

Purpose

Periodically monitors a cluster server's replicator-related activities

Target of the
test

A Domino application server

Agent
deploying the
test

An internal/remote agent

511

M o n i t o r i n g

Configurable
parameters for
the test

D o m i n o

A p p l i c a t i o n

S e r v e r s

1. TEST PERIOD - How often should the test be executed
2. HOST - The host for which the test is to be configured
3. PORT - The port number at which the specified HOST listens
4. SNMPPORT - The port number through which the server exposes its SNMP MIB.
The default value is 161.
5. SNMPVERSION – By default, the eG agent supports SNMP version 1. Accordingly,
the default selection in the SNMPVERSION list is v1. However, if a different SNMP
framework is in use in your environment, say SNMP v2 or v3, then select the
corresponding option from this list.
6. SNMPCOMMUNITY – The SNMP community name that the test uses to
communicate with the mail server. The default is public. This parameter is
specific to SNMP v1 and v2 only. Therefore, if the SNMPVERSION chosen is v3,
then this parameter will not appear.
7. USERNAME – This parameter appears only when v3 is selected as the
SNMPVERSION. SNMP version 3 (SNMPv3) is an extensible SNMP Framework
which supplements the SNMPv2 Framework, by additionally supporting message
security, access control, and remote SNMP configuration capabilities. To extract
performance statistics from the MIB using the highly secure SNMP v3 protocol,
the eG agent has to be configured with the required access privileges – in other
words, the eG agent should connect to the MIB using the credentials of a user
with access permissions to be MIB. Therefore, specify the name of such a user
against the USERNAME parameter.
8. AUTHPASS – Specify the password that corresponds to the above-mentioned
USERNAME. This parameter once again appears only if the SNMPVERSION
selected is v3.
9. CONFIRM PASSWORD – Confirm the AUTHPASS by retyping it here.
10. AUTHTYPE – This parameter too appears only if v3 is selected as the
SNMPVERSION. From the AUTHTYPE list box, choose the authentication
algorithm using which SNMP v3 converts the specified USERNAME and
PASSWORD into a 32-bit format to ensure security of SNMP transactions. You
can choose between the following options:



MD5 – Message Digest Algorithm



SHA – Secure Hash Algorithm



DES – Data Encryption Standard



AES – Advanced Encryption Standard

13. ENCRYPTPASSWORD – Specify the encryption password here.
14. CONFIRM PASSWORD – Confirm the encryption password by retyping it here.

512

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

15. TIMEOUT - Specify the duration (in seconds) within which the SNMP query
executed by this test should time out in the TIMEOUT text box. The default is 10
seconds.

Outputs of the
test
Measurements
made by the
test

One set of results for the Domino application server that is monitored

Measurement
Unit

Measurement
Successful replications:
Indicates the rate of successful
replications during the last
measurement period.
Replication failures:
Indicates the rate
replications during
measurement period.

of failed
the last

Replication docs added:

Replications
/Sec

Docs/Sec

Indicates the rate at which
replication docs were added
during the last measurement
period.
Replication docs deleted:

Docs/Sec

Indicates the rate at which
replication docs were deleted
during the last measurement
period.
Replication docs updated:

Docs/Sec

Indicates the rate at which
replication docs were updated
during the last measurement
period.
Avg work queue length:
Indicates the
queue
length
startup.

Number

average work
since
server

513

Interpretation

M o n i t o r i n g

D o m i n o

A p p l i c a t i o n

S e r v e r s

Current work queue length:

Number

If the value of this measure
increases consistently, it could
indicate a replication backlog - in
other words, too many databases
could be waiting to be replicated.
In
such
a
case,
consider
configuring more replicators on
the server so that replication
workload is shared and pending
replication requests are cleared in
a timely manner. Steady spikes in
this measure could also indicate
insufficient network bandwidth to
process the transactions. If this is
the case, you should consider
setting up a private LAN for your
cluster.

Secs

Since the cluster replicator checks
its queue every 15 seconds, this
number should be under 15
during periods of light load. If this
number is frequently higher than
30, you should consider adding
one or more cluster replicators.

Indicates the current number of
databases awaiting replication by
the cluster replicator.

Avg work queue wait time:
Indicates the average amount of
time in seconds that a database
spent on the work queue.

Data received rate:

KBytes/Sec

Indicates the rate at which data
was received by the replicator
during the last measurement
period.
Data sent rate:

KBytes/Sec

Indicates the rate at which data
was sent by the replicator during
the last measurement period.

514

C o n c l u s i o n

Chapter

17
Conclusion
This document has described in detail the monitoring paradigm used and the measurement
capabilities of the eG Enterprise suite of products with respect to application servers. For details of how
to administer and use the eG Enterprise suite of products, refer to the user manuals.
We will be adding new measurement capabilities into the future versions of the eG Enterprise suite. If
you can identify new capabilities that you would like us to incorporate in the eG Enterprise suite of
products, please contact support@eginnovations.com. We look forward to your support and
cooperation. Any feedback regarding this manual or any other aspects of the eG Enterprise suite can
be forwarded to feedback@eginnovations.com.

515

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Page Count                      : 522
Language                        : en-US
Tagged PDF                      : Yes
Title                           : Manual
Author                          : Geetha
Creator                         : Microsoft® Word 2013
Create Date                     : 2014:10:12 17:17:19+05:30
Modify Date                     : 2014:10:12 17:17:19+05:30
Producer                        : Microsoft® Word 2013

EXIF Metadata provided by EXIF.tools

Manual Monitoring Application Servers

Navigation menu

Versions of this User Manual:

Views

Navigation