Setting Up And Configuring Monitors

This article is an expansion pf my monitoring and engineering posts Perform the steps logically. It’s an overview built will keep you on focus of the things to do during monitoring setup.

• Check the documentation, knowledge based articles and support for the support level of the monitoring System Under Test (SUT). This will eliminate the possibility of unsupported monitors before moving on to the next step. 
• Configure the native monitor. Always ensure this is working before moving on to the configuration on Controller. Saves you time working backwards from the Controller. This is described as “Monitoring Environment Setup” in the documentations.
• Ensure connectivity by pinging and telnet the ports (dependent on the setup and the SUT). Sometimes, it’s just ports not being opened, or machines not in the correct network that is causing the problem. Do ensure that connectivity is available between all machines before moving to the next item.
• Configure the Controller machine / HP Performance Center to communicate to the SUT. This can consist of user privileges on the Controller / Performance Center machine or installing clients that will be used for the communication (e.g. Oracle or Sybase clients). 
• Lastly, configure the Controller through the GUI to connect to the native monitor. The last item on the list, and should not give you too much problem if (1) to (4) bullet points is properly done.

How Monitor works in Loadrunner?

It is ESSENTIAL to ensure the native monitors to be working before the actual load test. However, having all said, there will still be cases arising on failure in monitoring. I strongly recommend to take note on the following list which will assist you in a seamlessly setup. Usually, I give myself 2 to 3 days for monitoring and Performance environment setup before the load test just to ensure everything is working as expected with zero errors.

• No support for the native monitors. 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 and SSL handshakes. Ensure connectivity between the Controller / Performance Center 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 testing. (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.

Configuring Windows Native Monitor:

For Windows System Resource Monitoring, it requires (1) port 139 to be opened between Controller to the System Under Test (SUT) in a two-way traffic, (2) Perfmon to be working on the Controller, (3) Perfmon to be working on the SUT and (4) sufficient privileges to monitor the system.

Conventional SetUp

So what does conventional setup mean? It means you must ensure the following to before going even deeper.

1. Ping from the command prompt, Run > cmd the SUT from the Controller.
2. Telnet from the command prompt, Run > cmd the SUT from the Controller on port 139. Command as followed: telnet 139.
3. Telnet from the command prompt, Run > cmd the Controller from the SUT port 139. Command as followed: telnet 139.
4. Run Perfmon from SUT and Controller: Run > type “perfmon”.
5. Ensure that you have a equivalent user account on the Controller /Performance Center as well as the SUT for the perfmon to connect. E.g. if you are using loadtestadmin in Controller, loadtestadmin must exist in the SUT with administrator rights.
6. When you have successfully launched Perfmon, ensure that you are able to connect to the SUT and Controller vice versa by adding the Controller in the “Select Counters from computer:”. The data should be plotted accordingly.

Windows and Performance Monitor User privileges:

This is actually a simpler configuration as compared to the initial conventional method. If you have Windows, you can actually assign a privilege for monitoring.

1. Create a user account on both Controller and SUT. E.g loadtestadmin.
2. In the SUT, assign the user account with Performance Monitor User privileges! That’s all!
3. You should be able to monitor from there on Perfmon.

Monitoring using only User privileges:

There are always times that the security policy in the organisation does not permit admini11strator rights to be given to the load tester. We can assign Performance Monitor Us1111er privileges on Windows machines but what if we weren’t able to and only User privileges is allowed. No worries, below is the configuration needed for User privileges to monitor the resources:

1. Create a user account (eg. loadtestadmin) in Windows and grant it User privileges.

2. Allow the lists of registry and policy access for this user.

a. Required Registry with at least READ access for User Account:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Perflib
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
• HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

b. Required group policies with access for User Account:

• Profile single process
• Profile system performance

c. If %SystemRoot% is on an NTFS partition, must have at least READ access on the following files for User Account:

• %SystemRoot%\System32\Perfc009.dat
• %SystemRoot%\System32\Perfh009.dat

3. You should be able to monitor from there on Perfmon.

Troubleshooting Windows Resource Monitoring:

Account Lockout

In the event that you encountered a Account Lockout error, you can try the following which is actually extracted from Microsoft site for Windows NT 4.0.

In this release of Windows NT, your user account can become locked out when you try to connect to network resources using the Run dialog box (accessed by clicking Run on the Start menu). When this problem occurs, the following error message appears:

The referenced account is currently locked out and may not be logged on to.

This problem occurs when the following conditions are true:

• Account Lockout is enabled on the computer you are attempting to connect to.
• You have an identical account name on the computer you are attempting to connect to.
• The two accounts have different passwords.
• You are specifying a UNC path containing both the server and share names (for example, \\Server\Share).
• You are attempting to connect to the server using the Run dialog box (accessed by clicking Run on the Start menu).

This problem does not occur when you attempt to access a computer that is a member of the domain you are currently logged on to (but which also has a local account name that is identical to yours). This problem is more likely to occur in a work-group environment or between domains where there is no trust relationship.This problem occurs because Windows NT attempts the remote logon multiple times instead of displaying the Incorrect Password dialog box. Even if the server administrator increases the number of bad logon attempts that are allowed before account lockout occurs, for example to 10, the problem still occurs. After the sixth logon attempt the Incorrect Password dialog box appears and you are given the opportunity to enter the correct password. However, after you log off, log back on, and then attempt to connect to the same share again, your account is locked out due to the number of previously recorded bad logon attempts. If this problem occurs, map a drive by right-clicking on Network Neighborhood, clicking Map Network Drive, and entering the server and share information in the Path box.

Configuring the Oracle DB Monitor:

This will be discussed in a separate article. Thanks for reading the article. Happy Learning:)