How is the Information Gathered?
For the purposes of this discussion, we focus on obtaining performance information for an application and an application server; hardware back-end resources are beyond our scope. Different application servers expose their runtime metrics differently, but in an attempt to standardize on one mechanism, Sun released the Java Management Extensions (JMX) interfaces. Although not completely adopted by all application server vendors, BEA WebLogic, IBM WebSphere version 5 and higher, and JBoss have all implemented JMX as their preferred management API and thus expose their configuration and runtime information via JMX. Other vendors have other proprietary ways of gathering this information, either through exposed Servlets or command-line tools.
Applications, on the other hand, are a bit more work. Although some application servers watch the performance of their applications and report some rudimentary performance information, by and large the preferred mechanism for obtaining this information is through code instrumentation. Code instrumentation can occur either inside the architecture of your application (for example, you write the code to monitor your application and expose it somehow to the world) or through a separate process that automatically instruments your code. Most commercial vendors have implemented code instrumentation that connects into the application server's class loader so that you do not have to do anything special with your applicationjust deploy it to an application server that has instrumentation installed, and its classes will be automatically instrumented upon creation.
The amount of information collected during code instrumentation is usually configurable and can be as limited as recording the response time of specific methods and as broad as recording every transaction sent to the application server. The difference and the trade off is the impact and overhead of the instrumentation on your system; more instrumentation equates to a higher overhead, and vice versa.