Data we can collect with request metrics
Typically, different components of the enterprise application might be hosted across several nodes in a distributed system. For example, the servlets might be hosted on one node, while the enterprise beans on which these servlets depend might be hosted on an entirely different node. When a request comes to a process, the process might send the request to one or more downstream processes.
Trace records might be generated for each process with associated elapsed times for that process. These trace records might be correlated together to build a complete picture of the request flow through the distributed system, similar to the diagram in Why use request metrics?.
We can view the process response time that is monitored by request metrics through the Application Response Measurement (ARM) interface and system log files. When a request is sent to the application server, request metrics captures response times for the initiating request and any related downstream invocations. Request metrics are instrumented in the following components as the request, for example, transaction, travels through the web server, Proxy Server and the application server:
- Web server plug-in which is only available when using the web server port.
- Proxy Server, instrumented as servlet and web services requests.
- Web container, including servlet and servlet filters.
- EJB container.
- Java DataBase Connectivity (JDBC) calls.
- Java EE Connector Architecture (JCA).
- Web services, both on the server and the client side.
- Java Message Service (JMS) engine.
- Service Integration Bus (SIB).
- Portlet container, including the portlet requests.
- Asynchronous Beans.
Select the components to instrument. For example, if we want instrumentation data only for the web container and the JMS API, select this data in the administrative console and the detailed instrumentation data is generated only for the components that we select. The edge transactions are traced for the other components that are not specified for instrumentation.
When filtering is enabled, only requests that match the filter generate request metrics data, create log records, or call the ARM interfaces. We can add work into a running system specifically to generate trace information to evaluate the performance of specific types of requests in the context of normal load, ignoring requests from other sources that might affect the system. If the request matches any filter with a trace level greater than None, trace records are generated for that request.
Monitor application flow Why use request metrics? Getting performance data from request metrics