Request Metrics

 

To configure Request Metrics...

Admin Console | Troubleshooting | PMI Request Metrics  | Configuration tab 

Tasks include...

1. Enable Request Metrics.
2. Enable Application Response Measurement . (Optional)
3. Enable Request Metrics filters.
4. Add and remove Request Metrics filters.
5. Set the trace level in Request Metrics.
6. Update the Web server plug-in configuration file.

 

Enabling PMI Request Metrics filters

PMI Request Metrics compares each incoming request to a set of known filters, but you need to enable these filters.

1. Go to...

   Admin console | Troubleshooting | PMI Request Metrics | Filters | filter type

2. Select the check box in the enable field under the Configuration tab.

3. Click Apply and Save.

4. You can enable or disable a filter group.

5. If logging time spent in the Web server regenerate the Web server plug-in configuration file.

 

Adding and removing PMI Request Metrics filters

To add or remove PMI Request Metrics filters...

1. Open the administrative console.

2. Click Problem Determination > PMI Request Metrics in the console navigation tree.

3. Click filters.

4. Choose a filter type.

   1. Click on filterValues.

   2. You can edit, add, and delete a filter value. To edit, click on a filter value and change its value and enablement. To add, click on "New" and type in the value and optionally check the "Enable" box. To delete, select a filter value and click on "Delete".

5. Click Apply or OK.

6. Click Save.Individual filters are composed of an indicator and an IP address. Use the indicator to determine whether the individual filter is active. The IP address is in the IPv4 addressing format.

 

PMI Request Metrics data output

The trace records for PMI Request Metrics data are output to two log files: the web server plug-in log file and the appserver log file. The default directory for these log files is <$WAS_ROOT/logs/server> (or the name given to your server <$WAS-ROOT/logs/server>) and default names are SystemOut.log and http_plugin.log. Users may, however, specify these log file names and their locations.

In the WAS log file the trace record format is

PMRM0003I: parent:ver=n,ip=n.n.n.n,time=nnnnnnnnnn,pid=nnnn,reqid=nnnnnn,event=nnnn 
- 
current:ver=n,ip=n.n.n.n,time=nnnnnnnnnn,pid=nnnn,reqid=nnnnnn,event=nnnn 
           type=TTT detail=some_detail_information elapsed=nnnn

In the Web server plug-in log file the trace record format is

PLUGIN...
parent:ver=n,ip=n.n.n.n,time=nnnnnnnnnn,pid=nnnn,reqid=nnnnnn,event=nnnn 
- current:ver=n,ip=n.n.n.n,time=nnnnnnnnnn,pid=nnnn,reqid=nnnnnn,event=nnnn 
           type=TTT detail=some_detail_information elapsed=nnnn bytesIn=nnnn 
           bytesOut=nnnn

The trace record format is composed of two correlators: a parent correlator and current correlator. The parent correlator represents the upstream request and the current correlator represents the current operation. If the parent and current correlators are the same, then the record represents an operation that occurred as it entered WAS.

To correlate trace records for a particular request, collect records with a message ID of PMRM0003I from the appropriate appserver log files and the PLUGIN trace record from the Web server plug-in log file. Records are correlated by matching current correlators to parent correlators. The logical tree can be created by connecting the current correlators of parent trace records to the parent correlators of child records. This tree shows the progression of the request across the server cluster. Refer to Measuring data requests (PMI Request Metrics) for an example of the transaction flow.

The parent correlator is denoted by the comma separating fields following the keyword "parent:". Likewise, the current correlator is denoted by the comma separating fields following "current:".

The fields of both parent and current correlators are as follows...

• ver: The version of the correlator. For convenience, it is duplicated in both the parent and current correlators.

• ip: The IP address of the node of the appserver that generated the correlator.

• pid: The process ID of the appserver that generated the correlator.

• time: The start time of the appserver process that generated the correlator.

• reqid: An ID assigned to the request by Request Metrics, unique to the appserver process.

• event: An event ID assigned to differentiate the actual trace events.

Following the parent and current correlators, is the metrics data for timed operation...

• type: A code representing the type of operation being timed. Supported types include , URI, EJB and JDBC.

• detail: Identifies the name of the operation being timed (See the description of Universal Resource Identifier (URI), , Enterprise bean and JDBC below.)

• elapsed: The measured elapsed time in <units> for this operation, which includes all sub-operations called by this operation. The unit of elapsed time is milliseconds.

• bytesIn: The number of bytes from the request received by the Web server plug-in.

• bytesOut: The number of bytes from the reply sent from the Web server plug-in to the client.

The type and detail fields are described as follows...

• HTTP: The Web server plug-in generates the trace record. The detail is the name of the URI used to invoke the request.

• URI: The trace record was generated by a Web component. The URI is the name of the URI used to invoke the request.

• EJB: The fully qualified package and method name of the enterprise bean.

• JDBC: The values select, update, insert or delete for prepared statements. For non-prepared statements, the full statement can appear.

 

PMI Request Metrics trace filters

When PMI Request Metrics is active, trace filters control which requests get traced. The data is recorded to the system log file or sent through ARM for real-time and historical analysis.

Incoming HTTP requests

HTTP requests arriving at the WAS may be filtered based on the URI and/or the IP address of the originator of the request.

• Originator IP address filters Requests are filtered based on a known IP address. You can specify a mask for an IP address using the asterisk (*). If used, the asterisk must always be the last character of the mask, for example 127.0.0.*, 127.0.*, 127*. For performance reasons, the pattern matches character by character, until either an asterisk is found in the filter, a mismatch occurs, or the filters are found to be an exact match.

• URI filters. Requests are filtered, based on the URI of the incoming HTTP request. The rules for pattern matching are the same as for matching Originator IP address filters.

• Filter combinations.If both URI and Originator IP address filters are active, then Request Metrics requires a match for both filter types. If neither is active, all requests are considered a match.

Incoming enterprise bean requests

• Enterprise bean method name filters. Requests are filtered based on the full name of the enterprise bean method. As with IP address and URI filters, the asterisk (*) may be used in the mask. If used, the asterisk must always be the last character of a filter pattern.

Because the ability to track the request response times comes with a cost, filtering helps optimize performance when using Request Metrics.

Regenerate the Web server plug-in configuration file, if logging time spent in the Web server.

 

See Also

1. PMIRM Filter
2. filterValues
3. Setting the trace level in PMI Request

 

---