How the Monitor Works

The monitor will run the script in the Astra LoadTest (ALT) application. It is running through perfex, and will spawn an mdrv process to execute the script. Perfex is required so that the mdrv process will be created with the credentials supplied in the ALT Recorder page.

The script is run in exactly the same way as it is run under Astra LoadTest in load mode. Astra Load Test will use the credentials defined in the Recorder page.

The Astra LoadTest log files are kept in the SiteScope\cache\tempbysize directory. The monitor parses this log file to get the transaction times and errors/warnings. By default, SiteScope saves only the log files of failed runs. If the run finished successfully, the log is not saved. However If you want to keep all the log files, you have can open the SiteScope/groups/master.config file and set to "true" the following entry:

_astraKeepLogFiles=

How to Troubleshoot

1. Make sure you have Astra LoadTest version 5.4.3 or later. It must be installed on the same machine where SiteScope is running.

2. When setting up the script initially in ALT, you must define at least one Transaction while recording (with Start and Stop points), or the monitor will fail in SiteScope.

3. The credentials (in Recorder page) have to be the same as the user that was logged in when Astra LoadTest was installed.

4. Check that you can run the script in Astra LoadTest directly. If the script runs in Astra Load Test but times out in SiteScope, then use WinInet mode to execute the script instead. In order to switch between WinInet and Turbo replay you have to go to the RTS – Browser Configuration tab and check/uncheck the Use Turboload Technology option.

5. If you are running SiteScope service as a LocalSystem Account, add the user credentials located in the Astra LoadTest Runners Preference page. This is in the help manual at:

http://your SiteScope server name and port/SiteScope/docs/recorderPrefs.htm

SiteScope should run as an interactive service in the context of the LocalSystem account. It can be changed in Control Panel -> Services -> Sitescope -> Properties -> Log on. Select the Allow interaction with desktop checkbox.

6. Every time SiteScope restarts, it cleans up the oldest Astra LoadTest log files in the SiteScope/cache/tempbysize directory according to the max size limit defined for this directory in the SiteScope/groups/master.config file. The entry is:

_tempDirMaxSize=10000 (the size is in KB)

In SiteScope 7.8.1.0, there is no default value for that entry, and that will cause all the files in the directory to be deleted. There is a default of 10000 in SiteScope 7.8.1.2 and later. If the entry is not there, then add the above entry to the master.config file, save it, and restart SiteScope. After that, the log files should be kept until the directory gets to the limit defined.

Note – Astra Load Test has been deprecated as of SiteScope 7.9.0.0 or later. It is only available in these versions if SiteScope has been upgraded from a pre-7.9.0.0 version.

How to Troubleshoot the ASP Server Monitor

This monitor is an NT Performance Counter monitor. It is hard-coded to look for the "Active Server Pages" Performance Object.

How to Troubleshoot

1) Since this is a perfex-based monitor all the basic Perfex troubleshooting steps apply:

a) Do you have permissions to access the remote machine?

b) Is the "Active Server Pages" Performance Object available in perfmon?

i. If not this has to be enabled. Use exctrlst.exe from Microsoft to enable it if possible

ii.Are other Performance Objects available? If not maybe the Registry Service needs to be restarted.

2) While logged in to the SiteScope server as the same user that the SiteScope service is running as, open a command prompt and change to the SiteScope ools directory. SiteScope uses a program called perfex to connect to remote Windows Servers. You can run perfex from the command line to see what SiteScope is getting returned.

The specific perfex command to check whether the counters SiteScope needs are available is:

perfex remotemachine -u username -p password -o "Active Server Pages"

You may potentially run into problems with remotes due to network issues (if a firewall is blocking ports 137-139 for example — SiteScope uses Netbios) or server configuration problems (SiteScope, and perfmon, rely on certain services to be running on the remote like Remote Registry Service, RPC Service, Server, and TCP Netbios helper) or permissions issues.

Sometimes (very rarely), you may need to map a drive to the remote server using that same admin user SiteScope is trying to connect as before you can connect via PerfMon.

If the counters the you are looking for aren’t available to PerfMon then they won’t be available to SiteScope.

The important thing is that you should be able to run perfex and get a list of counters back for a particular object. If you don’t then there’s a problem. Perfex may return an error that will give you a good idea where to start:

ERROR: RegConnectRegistry, Unknown error (53)

Perfex – Add Connection Failed

The network path was not found.

It’s also useful to know that when you see an "Unknown error (x)" in relation to perfex or an NT Remote that "x" usually is an actual Windows error code. If you run the command below from a command promt:

net helpmsg x

then you should receive some information back. From that you can usually search Microsoft TechNet for the exact cause and resolution for the error message that Windows is generating.

If you receive only three lines back from your perfex run, like:

PerfTime: xxxxxxxxxxx

PerfFreq: yyyyyy

PerfTime100nSec: zzzzzzzzzzzzzzz

then you’ve connected to the machine but there’s likely a problem with the object you’re trying to retrieve info back on. For example, a good perfex run against the Active Server Pages object begins like this

D:SiteScope ools>perfex emoteserver -u username -p password -o "Active Server Pages"

PerfTime: 345768960591

PerfFreq: 3579545

PerfTime100nSec: 127274891202804869

object: Active Server Pages 5530

name: SINGLE

Debugging Requests: 0 PERF_COUNTER_RAWCOUNT

Errors During Script Runtime: 0 PERF_COUNTER_RAWCOUNT

Errors From ASP Preprocessor: 0 PERF_COUNTER_RAWCOUNT

Errors From Script Compilers: 0 PERF_COUNTER_RAWCOUNT

Errors/Sec: 0 /second PERF_COUNTER_COUNTER

Request Bytes In Total: 0 PERF_COUNTER_RAWCOUNT

Request Bytes Out Total: 0 PERF_COUNTER_RAWCOUNT

Request Execution Time: 0 PERF_COUNTER_RAWCOUNT

Request Wait Time: 0 PERF_COUNTER_RAWCOUNT

Requests Disconnected: 0 PERF_COUNTER_RAWCOUNT

Requests Executing: 0 PERF_COUNTER_RAWCOUNT

Requests Failed Total: 0 PERF_COUNTER_RAWCOUNT

Requests Not Authorized: 0 PERF_COUNTER_RAWCOUNT

Requests Not Found: 0 PERF_COUNTER_RAWCOUNT

Requests Queued: 0 PERF_COUNTER_RAWCOUNT

Requests Rejected: 0 PERF_COUNTER_RAWCOUNT

Requests Succeeded: 0 PERF_COUNTER_RAWCOUNT

Requests Timed Out: 0 PERF_COUNTER_RAWCOUNT

Requests Total: 0 PERF_COUNTER_RAWCOUNT

Requests/Sec: 0 /second PERF_COUNTER_COUNTER

Script Engines Cached: 0 PERF_COUNTER_RAWCOUNT

Session Duration: 0 PERF_COUNTER_RAWCOUNT

Sessions Current: 0 PERF_COUNTER_RAWCOUNT

Sessions Timed Out: 0 PERF_COUNTER_RAWCOUNT

Sessions Total: 0 PERF_COUNTER_RAWCOUNT

Templates Cached: 0 PERF_COUNTER_RAWCOUNT

Template Cache Hit Rate: 0 % PERF_RAW_FRACTION

empty: 0 PERF_RAW_BASE

Template Notifications: 0 PERF_COUNTER_RAWCOUNT

Transactions Aborted: 0 PERF_COUNTER_RAWCOUNT

Transactions Committed: 0 PERF_COUNTER_RAWCOUNT

Transactions Pending: 0 PERF_COUNTER_RAWCOUNT

Transactions Total: 0 PERF_COUNTER_RAWCOUNT

Transactions/Sec: 0 /second PERF_COUNTER_COUNTER

end perfex

There is a property called _counterObjectsASPMonitor that can be set in the master.config or even the group level that should allow the default Performance object to be modified from the default.

The default instance of Active Server Pages that the monitor checks for is "SINGLE" – if there is one with a different instance then that can be changed using the _counterInstanceASPMonitor property.

How to Troubleshoot the Apache Monitor

How it Works

Essentially the Apache Server Monitor is a URL Content Monitor designed to work specifically against the Apache server-status page. This page may not be enabled on the Apache server by default. See the Apache Web Server documentation for information on enabling this.

The counter list comes from the SiteScope templates.applicationscounters.apache file. Some counters are available only on the Unix release of Apache, the rest are available on both Unix and Windows.

Selecting the counters from this list tells SiteScope which values to report on. SiteScope builds a regular expression dynamically, depending on which counters are selected.

How to Troubleshoot

1) First try bringing up the server-status page in a regular browser:

http://servername/server-status?auto

For an example of what a status page looks like see Apache’s web site here:
http://www.apache.org/server-status?auto

If this is page is not available then the SiteScope monitor will not work. The server-status page must be enabled in Apache.

2) If the server-status page is available from outside of SiteScope but the SiteScope monitor is failing with an error like unable to connect to server or unable to reach server then check to see if possibly a proxy server is required. You can add configuration for a proxy server under the Advanced Options section of the monitor definition. Format for specifying a Proxy is:
hostname:port
not
http://hostname:port

3) A username and password might be required to access the server-status page – this can also be configured in the Advanced Options section of the monitor.

4) From the Apache Web Server documentation:

Note that mod_status will only work when you are running Apache in standalone mode and not inetd mode.

This goes back to the requirement of the monitor – the server-status page must be enabled. If it can’t be enabled due to the server running in inetd mode then the Apache monitor will not work (because the page won’t be available in Apache).