Network Deployment (Distributed operating systems), v8.0 > Monitor > Monitor application flow > Why use request metrics?
Data you 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, as shown in the following figure:
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:
- the web server plug-in which is only available when using the web server port.
- the Proxy Server, instrumented as servlet and web services requests.
- the web container, including servlet and servlet filters.
- the EJB container.
- Java DataBase Connectivity (JDBC) calls.
- Java EE Connector Architecture (JCA).
- Web services, both on the server and the client side.
- the JMS engine.
- Service Integration Bus (SIB).
- Portlet container, including the portlet requests.
- Asynchronous Beans.
Select the components to instrument. For example, if you want instrumentation data only for the web container and the JMS API, select this data in the admin console and the detailed instrumentation data is generated only for the components that you 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?
Get performance data from request metrics