The objective of LoadRunner is simple; to load an application (set upon a certain environment and hardware), monitor the servers that is in the environment housing the applications, and lastly collect the results for analysis. LoadRunner sells itself as a load testing tool that is not intrusive in any environment with the capability of not requiring installation of agent programs on the servers in the environment (anyway, most monitoring tools work in this way).  How is this achievable?

What LoadRunner does is to collect information of monitoring counters of the native monitors. Native monitors in this context mean the programs/modules that is in-built with the system that you are monitoring. Example of the commons, for monitoring Windows System Resources, LoadRunner draws information from the in-built tool, Perfmon which is available for almost all Windows OS. For Unix System Resources, LoadRunner uses rstatd daemon of Unix OS for monitoring.

For non-System Resources, such as Web Server Resources, Apache Web Server, the server must be configured to allow monitoring before LoadRunner can draw monitoring data out. This applies for Web Application Server such as BEA WebLogic and IBM WebSphere.  For Database Servers, there is an additional step that requires a client to be installed for the monitoring to be successful. Example, for Sybase Database, the Sybase AES client (if I do not remember wrongly) needs to be installed on the Controller; Oracle Database requires the V$SESSION table to be working. With the exception of MS SQL, where the counters are in-built into Perfmon.  Client programs that are required to installed also applies to WebLogic JMX Monitoring.  The list can go on however, the concept of monitoring is the same and applies for other monitors that is not mentioned in the above examples too. (More information of the monitoring requirements can be consulted in the Monitor Reference provided with each installation of LoadRunner.)

• No support for the native monitor; Check out the support level on the documentations, knowledge base articles and the support (if the information is not readily available online).
• Configuration problems on the native monitors; Check out and verify the configuration settings on the native monitors against the documentations and knowledge base articles.
• Environmental Issues such as security, firewall and policies; Ensure connectivity between the Controller and monitoring machines (dependent on the port number and how the load testing was implemented) and the access rights given to the load testing user.

A sound understanding of the native monitors (Perfmon, rstatd, etc) such as its configuration, type of monitoring data it can provide, and how it generally works will serve a good foundation before the load test. (Therefore quite a fair bit of reading and googling will do you good!) This will be useful for the load tester to relate the required configuration to the System Admin/Engineer, Network Engineers, etc and get the job done with minimal effort. (You need to talk their “language”!)

In summary, LoadRunner collects monitoring data from the native monitors. This requires the native monitors to be configured properly prior the load test. However, they do fail at times and it’s possible to scope down to either (1) no support, (2) configuration problem and (3) environmental issues that can resolved with adequate planning. Furthermore, a sound understanding of the native monitors will be useful when conveying instructions to the system/network team in configuring them.