WebSphere Application Server V7.0: Concepts ... - IBM Redbooks

Tracing
By setting the trace depth, you 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. For
application server layers, servlets, Web services, EJB, JDBC, and JMS, the
information is logged to the SystemOut.log for that application server. 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 you currently use a third-party tool that is ARM 4.0 compliant, the data can be
read by that agent as well. You can direct data to either the logs, the agent, or
both at the same time.
Note: 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)
ARM is an Open Group standard that defines the specification 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.
Chapter 7. Performance, scalability, and high availability 275