4 Monitoring Implementation Models
Posted: April 22nd, 2008 | Author: TnT Admin | Filed under: Concepts | Tags: Architecture, Monitoring | No Comments »Let’s touch on the monitoring implementation model for now. A new topic that was not covered in the predecessor site. You will benefit in understanding how to implement the the monitors in the testing environment as well as provide the requirements to the network and server teams to set the monitoring. In this article, we will be omitting the details of SiteScope and Diagnostics integration and the implementation for the moment and they will be discussed in future post! So stay tuned for that!
There are four implementations for monitoring without SiteScope and Diagnostics.
- Direct
- Open port on firewall
- Use one Mercury Agent inside the firewall
- Use two Mercury Agents: one Listener outside the firewall and one Monitoring Agent inside the firewall.
First, I presume you have a fundamental concept of how the monitoring works in LoadRunner. Bear this in mind so the discussion will be easily understood. If you are new to it, please refer to “How does monitoring work in LoadRunner?” to get a better understanding.
In [1], direct connection is required between the SUT (Server Under Test) usually inside a firewall; meaning the port is cleared and not blocked on the server. Also, prior to this the native monitor should already be working.
For example, Windows System Resources required port 139 to be opened. Therefore, ensure direct connectivity between the Controller and SUT on port 139.
In [2], where most environment is protected by a firewall, you have to lift the port that the Controller communicates to the SUT. Back to the same example, port 139 is to be lifted on the firewall to allow the monitoring data to be sent back.
Moving on to the 3rd and 4th implementation, the need for installing LoadRunner agents arises and this increases the complexity (but a little effort in understanding will definitely reduce it).
In [3], the full installation of LoadRunner (Controller) will install everything on the machine, resulting in the machine to have the LoadRunner agent. This agent is called the MI Listener, talks to the MOFW agent (Monitoring Over Firewall) for monitoring data on port 54345 (strange number huh?).
The MOFW agent which is actually installed (recommended standalone) inside the firewall. It also utilizes port 54345 to communicate back to the MI Listener. Put it simply, Controller talks to the MOFW on port 54345 in a two-way traffic.
From the MOFW agent onwards, it is the typical native monitoring ports that is required to be opened. For example, with the Window System Resources, the communication is as followed: (1) Controller to MOFW is 54345 and (2) MOFW to SUT is 139. Simple right?
In [4], the concept is similar to [3], however we extend the MI Listener as a separate machine by itself. This way, you will need to have port 50500 between the Controller and MI Listener. The communication between the MI Listener to MOFW now, is 443, the default SSL communication.
Example with Windows System Resources, you will need the following communication enabled: (1) Controller to MI Listener is 50500, (2) MI Listener to MOFW is 443 and (3) MOFW to SUT is 139.
Why do we have these monitoring implementations? There can be various reasons to it but will the following are some suggested or experienced so far:
1. For [1] and [2], it’s a simple setup through direct connection. The cavaet is, it’s security implication on opening the native ports which is usually disallowed. Example, port 139 datagram used by Windows System Resource Perfmon, is typically not allowed due to the security implication. Unless, the Controller and the SUT belongs to the same side of the firewall.
2. For [3], similar to [2], it attempts to open the port for communicating to the MOFW agent inside the firewall. In this implementation, it could be a situation that the agents had already been installed inside the firewall and all the Controller have to do is to connect to them. 54345 is not a popular port to be hacked I guessed.
3. For [4], is an attempt to use HTTP SSL (443) to communicate to the MOFW agents inside the firewall. This implementation proposed a secure way for communication as compared to lifting native monitoring ports (eg. 139).
4. For [3] and [4], you may have a dedicated machine to be a MOFW agent to collect monitoring data for every load test. This way, it’s more effective to just clear one port (either 443 or 54345).
5. For Unix System Resource monitoring which uses a dynamic port, the methods [3] and [4] is clearly more efficient for any port clearance procedures where the Controller connects to the MOFW on 54345 and MOFW connects to the Unix box on the dynamic port (no port lifting is required except 54345 is needed on the firewall).
So well, in summary, we covered the implemtation models in a general overview with the ports required and the benefits and cavaets each of them may have. This should be useful to you in planning the monitoring setup as well as
Leave a Reply