Tasks Implementing request metrics
There are several methods for implementing request metrics. This section briefly discusses the methods that are currently available.
Request filtering
The most common method of implementing request metrics is to use request filtering. In this method, we use filters to limit the number of transactions that are logged, capturing only those transactions we care to monitor. As an example, we can use an IP address filter to monitor synthetic transactions that always come from the same server. Some of the available filters are as follows:
HTTP requests Filtered by IP address, URI, or both Enterprise bean requests Filtered by method name JMS requests Filtered by parameters Web services requests Filtered by parameters Source IP filters
The performance impact is less than 5% when all incoming transactions are being instrumented. This is not a significant amount, but factor this in when implementing the metrics. The path for implementation in the Integrated Solutions Console is through...
Monitoring and Tuning | Request Metrics
Tracing
By setting the trace depth, we control not only the depth of information gathered through the metric, but also the overall performance impact on the system. The higher a tracing level, the greater the performance penalty the system takes. There are several available trace levels:
None No data captured Hops Process boundaries (Web server, servlet, EJB over RMI-IIOP) Performance_debug Hops + 1 level of intraprocess calls Debug Full capture (all cross-process/intraprocess calls) Set the tracing levels in the Integrated Solutions Console by navigating to...
Monitoring and Tuning | Request Metrics
Output for request metrics
The data captured by request metrics is placed in several levels, depending on the nature of the metric selected. For Web requests, the HTTP request is logged to the output file specified in the plugin-cfg.xml file on the Web server.Information is logged to the SystemOut.log for...
- servlets
- Web services
- EJB
- JDBC
- JMS
The data can also be output to an ARM agent and visualized using an ARM management software, such as IBM Tivoli Monitoring for Transaction Performance or IBM Enterprise Workload Management.
If we currently use a third-party tool that is ARM 4.0 compliant, the data can be read by that agent as well. We can direct data to either the logs, the agent, or both at the same time.
It is suggested not to use metric logging while implementing the ARM agent monitoring, because the disk I/O can negatively impact performance.
Application Response Measurement (ARM) is an Open Group standard that defines the spec and APIs for per-transaction performance monitoring. Request metrics can be configured to use ARM. In doing so, the request metrics use call across the ARM API to gather the data.
WebSphere request metrics support the Open Group ARM 4.0 Standard, as well as the Tivoli ARM 2.0. The 4.0 standard is supported in all components. For the Tivoli standard, WAS V7.0 supports all components except Web server plug-ins. A correlator can be extracted from request metrics transactions. This correlator can be passed to sub-transactions taking place in non-WebSphere containers. This facility allows the complete transaction to be accurately timed in complex environments.
Additional resources
For additional information about ARM and the WebSphere request metrics implementation...
- ARM 4.0 spec
- Information about the ARM standard
- IBM Tivoli Monitoring for Transaction Performance
- IBM Enterprise Workload Management