How do I use the SetRMFilters and RequestMetrics Knowledge Scripts? (NETIQKB37023)

  • 7737023
  • 02-Feb-2007
  • 08-Sep-2008


How do I use the SetRMFilters and RequestMetrics Knowledge Scripts?

AppManager 5.x

WebSphereAppSrvUNIX_SetRMFilters Knowledge Script

WebSphereAppSrvUNIX_RequestMetrics Knowledge Script

WebSphereAppSrv_SetRMFilters Knowledge Script

WebSphereAppSrv_RequestMetrics Knowledge Script

WebSphere Application Server 4.x

WebSphere Application Server 5.x


The RequestMetrics Knowledge Script is used to gather and correlate request metrics traces written to WebSphere JVM log files.  It is most useful in network deployment scenarios, where a request enters the WebSphere cell via the servlet container running within a particular application server, and then makes calls to EJBs running elsewhere on the network.

In order to make Request Metrics traces available for gathering by the RequestMetrics Knowledge Script, you must first run two other Knowledge Scripts.  First, if you have configured WebSphere to write its JVM standard output log file in a non-default location (or with a non-default filename), you will need to run the SetServerLogPath Knowledge Script to tell the NetIQ Agent where the JVM log file is located.  This must be done on each machine on which the JVM log file is stored in a non-default location, or with a non-default filename.

Next, you must run the SetRMFilters Knowledge Script to tell WebSphere which traces are to be written to the application servers' JVM log files.  Once this script has been executed, WebSphere application servers will write traces which match the specified filters during request processing.  Therefore, SetRMFilters must be run once before the RequestMetrics Knowledge Script is run, since otherwise no traces will be available for correlation and analysis.  In a network deployment, you need to run the SetRMFilters Knowledge Script only against the deployment manager node, since Request Metrics filters are a global setting which will affect all servers in the deployment cell.

Once SetRMFilters has been used to initialize the trace filtering, the RequestMetrics Knowledge Script can be used to gather and correlate the traces.  The RequestMetrics Knowledge Script must be run against the application server that houses the servlet container which is the entry point for application server requests.  Only those traces which are found to be associated with a request entering the system at the application server on which the RequestMetrics script is run will be considered during processing.

When the RequestMetrics Knowledge Script is run, you must specify a list of hosts (hostnames or IP addresses) to be contacted.  This host list should include all machines that might be involved in processing of requests which enter the system at the application server on which the Knowledge Script is dropped.  (The machine that hosts the server on which you drop the Knowledge Script will automatically be included in this list -- you don't need to type it in manually, although it will not cause any problems if you do so.)  In addition, the NetIQ Agent must be running on each of the referenced hosts (and listening on the same port on each host), so that it can be contacted by the Knowledge Script and asked to scan for Request Metrics traces and return them to the Knowledge Script for correlation.  You can ensure that the NetIQ Agent is running by executing the NetIQAgent Knowledge Script, .
which will start the agent running if it is not already doing so.

The RequestMetrics Knowledge Script creates a datastream containing the average response time for all requests which match the Request Metrics filters specified by SetRMFilters, whose entry point was the servlet container running in the application server on which the Knowledge Script was dropped.  In addition, if you specify a response time threshold, and the threshold is exceeded, the RequestMetrics script will trigger a threshold event.  Included in this event is a breakdown of how much time was spent doing servlet processing, along with how much time was spent calling EJB methods and making JDBC database calls.  Note that this breakdown is not included with each response time data point -- the only way to receive the response time breakdown is to specify a threshold, and to have that threshold exceeded..

Additional Information

Formerly known as NETIQKB37023