MySQL database monitoring will require SiteScope to be deployed acting as a bridging collector before it can be displayed in LoadRunner. The connection is illustrated in the following.

The specified statistics retrieval mechanism utilizes Database Query monitor in SiteScope. This is done by logging into MySQL database via SiteScope Database Query monitor and issuing a SHOW STATUS command to retrieve the statistics. Example of the command is as followed:

show status where variable_name like ’innodb_buffer_pool_pages_total’

Therefore, prior this monitor setup, SiteScope should already be deployed or considered in the deployment. Refer to SiteScope setup for more information. The ports between LoadRunner and SiteScope, SiteScope and MySQL should be opened on TCP 8888 and TCP 3306 respectively by default. On top of this basic requirement, monitoring a MySQL database requires the use of JDBC Driver, which SiteScope uses to interact with the MySQL database.

In summary, what you need before the setup is as followed.

1. SiteScope to be deployed.
2. Sufficient license points for Database Query monitor.
3. TCP 8888 (default) opened two-way for LoadRunner to SiteScope.
4. TCP 3306 (default) opened two-way for SiteScope to MySQL.
5. Monitoring privileges for SiteScope to monitor MySQL.
6. JDBC driver to be installed on SiteScope.
7. Have knowledge of the counter you want to monitor.

Let’s go into the details!

1. Download the JDBC driver from MySQL Download Connectors page.
2. Uncompress the distribution file.
3. Among all the other files, find and extract a file with .jar extension to Sitescope/java/lib/ext directory. (Source: SiteScope Monitor Guide)
4. Gather information about the hostname of the server and the database instance prior this step. In SiteScope console, add Database Query monitor to the existing monitoring group for the server (refer to SiteScope User Guide for more information). You should have the Name the monitor as mysql-{status_variable} to standardize the monitors (e.g. mysql-innodb_buffer_pool_pages_total).
5. In the settings enter the following:

Fig. 2 SiteScope Settings

Frequencies

What SiteScope documentation proposes is:

- For most critical and common query 2-5min.
- Database statistics that change less frequently can be monitored every 30 or 60min.

(Source: SiteScope Monitor Guide)

As for me, what I feel is to run the query at about 15-30secs interval as typical LoadRunner monitoring, it is defaulted at 15 secs. However by doing so, it may create additional overhead for making the query.

Database Connection

• Enter in the following format: Jdbc:mysql://{database hostname}[:{tcp port}]/{database}
• E.g. jdbc:mysql://DB-MySQL01:3306/mysql

Database Driver

• Enter following: org.gjt.mm.mysql.Driver (This Database Driver only applies for MySQL JDBC driver)

Query

• Enter the Command Line for Query to Database
• E.g. show status where variable_name like ’innodb_buffer_pool_pages_total’
• You can also run queries that directly execute on table based on your needs!

Advanced Settings

• Enter Database User Name and Database Password for logging in of MySQL Database. I’m using root account to execute the query. I’m not too sure if there is any possibility of knowing the correct privilege needed to monitor. If you do, please let us know.

Upon successful connection, you will prompt with ‘Successful Connection’ and the time Sitescope took to Query MySQL Database.

If you need to monitor another MySQL counter, a new monitor needs to be created. Example, if you want to monitor the Qcache_hits, you will have to perform step 4 to step 5 again for this new counter. Do ensure you have sufficient SiteScope license points for another monitor!

This concludes the monitoring for MySQL database server. Point to note that the queries executed may cause overhead to the database server which may required you to balance the pros and cons to implement this monitor.

1. LoadRunner may not haveas much monitors as compared to SiteScope. So with SiteScope, you can use it to enhance or compliment the existing monitors in LoadRunner. E.g. you can use the URL monitor to determine if the server is alive while during the load test instead of just seeing errors occurring.

2. SiteScope provides additional monitoring feature for Unix flavored OS by using HTTP, rlogin, telnet and SSH as compared to only rstatd in LoadRunner. rstatd is restrictive as it utilizes a dynamic port. This is especially problematic when you have port clearance to deal with as you will not be able to determine the ports being used. Also, rstatd only provides basic monitoring information for the Unix box. By using telnet, rlogin and SSH, we are able to customize the type of monitoring information we want from Unix by amending the commands issued to the Unix box, such as sar and vmstat.

3. SiteScope provides a centralize monitoring which allows deployment of monitors easily. This is achieved through creation of templates which also allows the standardization of monitor data across all load test project easily. Standardization can still be achieved in LoadRunner, but it is done via manual additional or Standard Operating Procedures (SOP).

4. If you are working in one single environment, it makes things even simpler as the SiteScope server will become the main central server to monitor the environment. All you are required to do is to ensure that port 8888 (default) is accessible from LoadRunner to SiteScope.

I’m still experimenting the different ways that I can capitalize SiteScope with LoadRunner and will update you in future if I’ve found new stuff along the way. Currently, looking at Linux speciiffied Would like to hear from you too if you have other ways of maximizing the usage of SiteScope!

Before we start (running the installer), lets get some basic understanding of how SiteScope works. For SiteScope to integrate with LoadRunner or communicate as per say, it’s very simple. SiteScope has a default port 8888 that displays the collected monitoring data as a XML page, and what LoadRunner does (same concept behind native monitors, refer to “How does the monitoring work in LoadRunner?“), is to retrieve the statistics off the SiteScope XML page via port 8888.

Note:

SiteScope’s default port can be changed at the administration console. Refer to the “SiteScope Administration Guide” for more information on this. If you changed the ports in SiteScope, you will need to change the port which LoadRunner connects to SiteScope as well. This is covered in “How to specify the information in the Controller if SiteScope is not running on the default port (8888)”.

Therefore, before you start the integration, you need to ensure two things:

1. Port 8888 (default) is opened two way between SiteScope and LoadRunner machines.
2. XML page is displaying monitoring data.
3. SiteScope is already collecting statistics from the SUT (System Under Test) and displaying it on it’s machine

Take note, SiteScope and LoadRunner works the same way in monitoring. (Refer to “How does the monitoring work in LoadRunner?“). SiteScope utilizes Perfmon to collect statistics from Window servers. As such, the same thing apply, you will need an account in the Windows server and port 139 to be opened two-way from the SiteScope machine to the Windows machine. Once, you’re able to see the monitoring data in SiteScope, you can move on to the LoadRunner portion. I will leave the configuration of the connecting the SiteScope to Windows server to the SiteScope User Guide.

The following illustrates an implementation of a load test on the monitoring via SiteScope. Click on it to view the enlarge version.

Using Windows server as an overview example, you will have to go through the following steps:

1. Ensure that Perfmon is working on the Windows machine.
2. Ensure that SiteScope has an account to access the Windows machine.
3. Ensure that port 139 is opened between Windows and SiteScope machine.
4. Ensure that SiteScope is receiving monitoring data.
5. Connect the SiteScope to LoadRunner in Controller.
6. Ensure that LoadRunner is displaying the statistics in Controller.

We’ve covered briefly but should be sufficient for you to know the requirements needed when implementing SiteScope as the monitoring mechanism for LoadRunner. For the actual details of the setup, you may like to consult the user manuals as they provide details of step-by-step procedures.

Warning:
The installer has detected a system restart is required.
Click Cancel to exit the installation. After restarting the system, run the installation again.

Lately, I’ve encountered this problem while installing my SiteScope version 8.5 as the monitoring mechanism for my LoadRunner. I couldn’t find any information relating to it and so, logged a support case with HP Support. Below is the screenshot of the warning. Click on image to enlarge.

I’ve attached the log files which was generated during the installation. They are found in the %TEMP%\Mercury directory (e.g. C:\Documents and Settings\Administrator\Local Settings\Temp\Mercury). The files should be in the following format.

Mercury_SiteScope.{numeric string}.install.html
Mercury_SiteScope.{numeric string}.install.is.log

Click on the link to view an example of the content in the log files when the installation warning occur.

Mercury_SiteScope.01.07.11.01.install.html
Mercury_SiteScope.01.07.11.01.install.is.log

The solution provided is as followed (with some minor amendments while I was executing it). It looks at two registry keys namely [1] PendingFileRenameOperations and [2] RunOnce keys. Perform [1] before proceeding to [2]. Do remember to backup the registry before performing the following tasks (if you are unsure of the changes).

[1] PendingFileRenameOperations Registry

1. Go to following registry Key:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager2. Open PendingFileRenameOperations key. It will show the file name that will be renamed when you reboot.

3. If the file pointed by the above key doesn’t exist delete PendingFileRenameOperations key and run installation again.

4. If file exist, it means you should reboot the machine at least once and if you still get the message after reboot, you can delete the key.

If it still fails with the message that you need to reboot, go to [2].

[2] RunOnce Registry

1. Go to registry Key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\2. When you select RunOnce key, in the right hand side pane you will see multiple values and the first one is “Default”

3. Make a backup of the entries in the RunOnce key (right click > Export > Save).

4. Delete all other entry except “Default”.

5. If there is only one entry (”Default”), there is no need to delete anything.

6. Repeat same Step 1-5 for HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\

Both solutions should resolve the problem, but do remember to perform [1] before trying out [2]. Hope this is useful to you!

With SiteScope, you are able to receive the real-time information from the components in your infrastructure and stay abreast of any performance issues or bottlenecks with alerts and reports. For more information with regards to the sales talk (as usual), you can refer to the official vendor. What’s beneficial about SiteScope? SiteScope utilizies agentless monitoring technology that is similar to LoadRunner (refer to “How does the monitoring work in LoadRunner?” for information on LoadRunner monitoring mechanism) which eliminates the need for installation of (intrusive) agents on the system being monitored. What it does is to query native monitors on the infrastructure components for performance data and consolidate the information on the central SiteScope server.

One other key feature that SiteScope has to offer is the used of group templates. It allows standardization of monitoring the organization and speeding the monitoring deployment through groups and alerts. Also, not to mentioned that SiteScope is fully integrated with other HP solutions such as, HP Business Availability Center (BAC), HP Managed Software Solutions, and HP LoadRunner which allows added capabilities in monitoring for different product range. SiteScope is licensed based on point system instead of the number of servers you are installed SiteScope. A given point is been deducted based on the number of metric (monitors) you deployed. E.g. If you are monitoring CPU Utilization and Database which cost 1 point each. And you have purchased a 100 points license, the remainder of the available points will be 98 points which you can deploy for other monitorings. When you do not wish to use the monitor the CPU Utilization and Database anymore, the points are being released and you will have the initial 100 points. For more information on the licensing, we highly recommend you to go through the article, “Document ID 50972 – Licensing features of SiteScope” from the support site. Note: A metric is a system resource value, performance parameter, URL, or similar system response.