Troubleshooting the Astra Load Test Monitor

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.

Advertisements

Troubleshooting the ASP Server Monitor

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.

Troubleshooting the Apache Monitor

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).

Firefox browser is crashing during replay of AJAX Truclient script

Please follow these steps if the Firefox browser is crashing during replay of AJAX Truclient script :

  1. Disable Data Execution Prevention (DEP) in the boot.ini file for Windows 2003 and Windows XP and using bcdedit.exe for Windows 7 and 2008.
  2. Check with Process Explorer if any antivirus is getting hooked to vugen.exe and firefox.exe. If so, please disable the antivirus.
  3. Modify the default.cfg file in the script folder and add the following:

MeasurementLevel=0

ComponentBreakdown=0

Those keys control the collection of request/response information for analysis. Usually the crash does not happen in load mode replay.

Disable those options only for debugging purposes – interactive replay.

Make sure they are removed before using the script for load testing.

Troubleshooting the BMC Patrol (Classic) Alert Monitor

Monitor Type: BMC PATROL (Classic) Alert Monitor

Availability: Windows only

SiteScope Versions: 8.x is radically redesigned compared to the SiteScope 7.9.5.x version.

General category: EMS

How it Works in SiteScope 8.x:

The BMC PATROL Event Monitor requires a custom PATROL knowledge module to be installed on one central agent and a second PATROL knowledge module to be installed on all PATROL Agents whose events you want to integrate with Mercury Business Availability Center. Once the BMC Patrol Event Monitor/KM combination is installed and configured, every new BMC PATROL event is transferred to the Mercury Business Availability Center installation. In addition to transferring the BMC PATROL events to Mercury Business Availability Center, the BMC Patrol Event Monitor is capable of discovering the configuration of BMC PATROL Agents on a subnet. The configuration is then available to the Mercury Business Availability Center Dashboard.

Operating Environments:

This monitor must be used in conjunction with two KMs installed on BMC PATROL Agents. The KMs are responsible for delivering Open events to the BMC Patrol Event Monitor. The BMC Patrol Event Monitor collates events as reported from BMC PATROL Agents into unified samples and delivers these samples to the Mercury Business Availability Center server. You can use the configuration file for the BMC Patrol Event Monitor to control the data that is sent from SiteScope to Business Availability Center. The Patrol Agent/Console must be installed on the SiteScope machine. This enables the use of the Patrol Agent Open API which is needed for discovering the BMC configuration process. Discovering the BMC configuration process requires access to the files pemapi.dll and acmmls32.dll. These files are available as part of either the BMC Patrol Agent or the BMC Patrol Console, and are usually located in the [%PATROL_HOME]/bin folder. To ensure that the monitor can access the files, you must specify the path to the files, unless the location of the files is already specified in the %PATH% (search path).

Note: If you are working with BMC secure environment, you have to set your environment to enable use of PATROL components (use of pemapi component for example). Otherwise, configuration retrieval is not possible.

Limitations:

If you work with Mercury Business Availability Center version 5.1 and lower, you cannot define new BMC monitors or edit existing ones within Mercury Business Availability Centers Monitor Administration. This is because of variances in the user interface. You define new monitors or edit existing ones using the SiteScope interface. First detach the SiteScope from Monitor Administration, define or edit the monitor, and then reattach the SiteScope to Monitor Administration. The BMC monitor should be defined or edited only in SiteScope new user interface.

About Scheduling This Monitor:

Since the reading and status collected by the BMC Patrol Event Monitor include only statistical information, the monitor does not have to be scheduled very often. Scheduling the BMC Patrol Event Monitor to run every 10 minutes should be sufficient.

Reading and Status:

The monitor reading shows the number of events received since the last scheduled update or manual refresh, together with the number of currently connected agents. Note: The event counter goes down to zero each time the monitor is refreshed. This is expected behavior.

Integration Architecture:

The integration consists of one central agent that receives events from all the agents whose events you want passed to Mercury Business Availability Center. The connection between the remote agents and the central agents is be done using BMC communication (BMC secure channel). The connection between the central agent and SiteScope is done using a TCP socket to the SiteScope BMC monitor. If the central agent is installed on the SiteScope host, the integration is fully secured. It is recommended not to install a SiteScope with many configurations and many running monitors on the same machine as the central agent. It is preferable to choose a SiteScope with fewer monitors and fewer configurations for this purpose. If you choose to install SiteScope on a separate machine and you work with a secure environment, you must install SiteScope with one of the secured BMC agent?s machine to enable the configuration retrieval. The integration forwards all open, acknowledged, or closed events of BMC class 9, 11, 39. Events that have a status of acknowledged or closed may be forwarded with a five minute delay. This is because the process for checking these statuses (acknowledge and close) runs only every five minutes to avoid high CPU utilization.

KM Installation and Configuration:

The KM must be installed and configured on the BMC agent machines in order to have the events forwarded to SiteScope and then to Mercury Business Availability Center. The following are the procedures you follow to install and configure the KM package.

Installing the Mercury_Central_Agent.km on the Central Agent:

The central agent should be installed on the SiteScope machine. The integration uses BMC sending channels which are secured. By installing the BMC central agent on the SiteScope machine itself, full secure integration is ensured. You can install the central agent on a machine that is not the SiteScope machine but then the channel between the central agent and the SiteScope machine will not be secure. To install the Mercury_Central_Agent.km on the Central Agent:

1. Navigate to \conf\ems\bmc\addon\central.

2. From that location, copy mercury_central_agent library to [BMC root directory]\Patrol3.

3. From the same location copy Mercury_Central_Agent.km and Mercury_Remote_Messages.ctg to [BMC root directory]\Patrol3\lib\knowledge directory.

4. Open the PATROL Developer Console.

5. Use File > Load KM menu to load the Mercury_Central_Agent.km file (change the Files of Type selection to KM files to display the Mercury_Central_Agent.km file).

6. Select the Desktop tab. Under the Central Agent host, right click the Mercury_Central_Agent.km file and choose KM Commands -> CreateCentralAgentConnectionParams. This creates the file central_agent_params.ini in the [BMC root directory]\Patrol3\mercury_central_agent directory. This file contains the details of the central agent to be used by all remote agents. This file is necessary for the deployment of all remote agents.

7. Copy the generated file to [SiteScope root directory]\conf\ems\bmc\addon\remote\mercury_remote_agent directory.

Configuring the Central Agent:

Use the following procedure to configure the central agent to configure the Central Agent machine:

1. Select the Desktop tab. Right-click each host and select Development -> Agent Configuration. Warning: Use care when working with the Console in developer mode. Changes that you make may destroy data or configuration settings.

2. On the configuration window, browse to MERCURY/BAC.

3. In the right section, double click SiteScope_Address.

4. Double click REPLACE = ?127.0.0.1? (or any other value that is set).

5. Change the value to the IP address of the SiteScope machine that you will use to configure the BMC Patrol Event Monitor. Click OK.

6. Double click REPLACE = ?1789? (or any other value that is set).

7. Change the value to the port that is used for monitoring this group of Patrol agents with the BMC Patrol Event Monitor. Click OK.

8. Click OK.

9. Choose Tools -> Apply Configuration.

10. Select the central host to which you want to apply the configuration changes. Click OK.

11. Close the configuration window (there is no need to save).

Installing the Mercury_Remote_Messages.km on Remote Agents

Follow this procedure for each remote agent to install the Mercury_Remote_Messages.km on remote agents:

1. Deploy the directory [SiteScope root directory]\conf\ems\bmc\addon\remote\mercury_remote_agent (containing the generated file) to all remote agents under [BMC root directory]\Patrol3.

2. Deploy from [SiteScope root directory]\conf\ems\bmc\addon\remote the files Mercury_Remote_Messages.km and Mercury_Remote_Messages.ctg to the [BMC root directory]\Patrol3\lib\knowledge directory in all remote agents.

3. For all remote agents, load the Mercury_Remote_Messages.km.

General Agent Configuration:

Each agent saves its events in case these events cannot be forwarded. The default time limit is fifteen minutes. The time limit is to prevent the flooding of events to SiteScope during a long period that there is no communication from the agent. The time period to save the events can be modified with the following procedure. To modify the time period to save events on the agent:

1. Open the PATROL Developer Console.

2. Select Development -> Agent Configuration.

3. In the left screen, select the MERCURY/BAC directory.

4. In the right screen, double click on the variable RangeSaveEvents.

5. In the small box, double click Replace.

6. In the dialog box that opens, enter the number of minutes to save the events.

7. Click OK to save and close.

8. Select Tools -> Apply Configuration.

9. Choose the applicable server and click OK.

10. Close the window (there is no need to save).

Configure the KM for Preload:

You should configure the KM modules to be preloaded by the agent after you have completed the installation. This will configure the KM to be loaded whenever the agent is restarted. It also eliminates the need for the console to be open for the KM to be loaded and accessible. To configure the KM for preload:

1. Open the PATROL Developer Console.

2. Select Development -> Agent Configuration.

3. In the left screen, select the agent setup directory.

4. In the right screen, double click the variable preLoadedKm.

5. In the small box, double click Replace.

6. In the dialog box that opens, enter the name of the km (Mercury_Central_Agent.km or Mercury_Remote_Messages.km).

7. Click OK to save and close.

8. Select Tools -> Apply Configuration.

9. Choose the applicable server and click OK.

10. Close the window (there is no need to save).

Connectivity Settings:

There are four ways in which the monitor can be configured to connect to the BMC agent. You can change this configuration by editing the Patrol monitor configuration file found at [SiteScope root directory]\conf\ems\bmc\bmc_comm.cfg. Every change in that file requires restarting the SiteScope server. The options are:

Use a UDP protocol when attempting to connect to the BMC agent and ping the agent before trying to connect to it (PROTOCOL=UDP, PING=1). Using this option, the monitor will ping the agent before trying to connect to it and only if the agent is accessible, will it connect to it using UDP protocol.

Use UDP protocol when attempting to connect to the BMC agent and do not ping the agent before trying to connect to it (PROTOCOL=UDP, PING=0). Using this option, the monitor will connect to the agent using UDP protocol without checking if it is accessible.

Use TCP protocol when attempting to connect to the BMC agent and do not ping the agent before trying to connect to it (PROTOCOL=TCP, PING=0). Keep in mind that when using this option, there is TCP access to the agent. The BMC API function which is used to connect the agent is a blocking function. This means that the function will wait until it acquires a connection to the agent. This can last around four minutes (depending on the OS) and may cause socket exceptions and bad monitoring functionality. Use this option only if you are sure that you have TCP access to all the agents.

Use TCP protocol when attempting to connect the BMC agent and ping the agent before trying to connect to it (PROTOCOL=TCP, PING=1). This is the default behavior. The monitor will check if the agent is accessible by trying to ping it. Only if the agent is accessible, will the monitor try to connect the agent through TCP protocol. Using this option ensures that the BMC API function does not wait for the connection and does not cause undesirable results.

How to Troubleshoot:

Connectivity Diagnostics:

You use the following steps to verify connectivity with the PATROL agents. To verify connectivity to the PATROL Agent(s): 1. After installing the PATROL monitor, open a command prompt window, and change the working directory to the [SiteScope root directory]\bin directory.

2. Run the PATROL connection diagnostic utility, bmc_mercury_tools, using the following command line syntax:

a. bmc_mercury_tools <server name> <user name> <port number> where the command line arguments are defined as follows:

b. <server name> – targeted BMC PATROL Agent computer name

c. <user name> – PATROL user name with permissions to contact the above PATROL Agent

d. <port number> – PATROL Agent connection port (usually 3181)

e. You will be prompted for a corresponding password.

3.If the connection is successful, the following file will be created in the location indicated: [SiteScope root directory]/bin/BmcMercuryToolsXmlData.xml. 4. The BmcMercuryToolsXmlData.xml describes the metrics sampled by the PATROL Agent in XML format. In addition to the log files, five results of CPU Processor Time Percent are displayed on the console. Note: If the remote PATROL Agent is running on UNIX, the CPU Processor Time Percent metrics will be reported as errors. These errors do not necessarily indicate failure to connect to the PATROL Agent. This is because the test is trying to sample nt_cpu which does not exist on UNIX machines.

5. If the connection fails, an error message is reported. Additional information is available in the file [SiteScope root directory]\logs\bmc_mercury_comm.txt.

6. SiteScope cannot be deployed behind a firewall. The SiteScope and the monitored system must be on the same LAN or special firewall configuration may be required.

Final notes:

· PATROL Mercury Application Management Integration TCP Port – Enter the TCP port number as configured in the PTI Application. By default, default TCP port number 1789 is used. If you need to use a different port number, see the section ?KM Installation and Configuration? on page 995 for instructions on how to configure the port number.

· Old Add-on Installed – Select only if your BMC system has PTI installed. PTI is the add-on that was used in previous versions to connect between BMC and SiteScope. If you are upgrading from SiteScope 7.9.5.0 and you already have defined monitors that work with the old PTI, they are automatically marked as working with old add-on installed.

· UDP Communication Protocol – Select this option if you want to use UDP as the communication protocol when getting topology data from the BMC agents. The default communication protocol is TCP. There are four options to use in configuring the monitor to connect to the BMC agent to retrieve configuration data.

· The pdf mentions that In addition to transferring the BMC PATROL events to Mercury Business Availability Center, the BMC Patrol Event Monitor is capable of discovering the configuration of BMC PATROL Agents on a subnet. The configuration is then available to the Mercury Business Availability Center Dashboard. How does it do that? – We use Patrol API which called pemapi (that is the reason that we need to install BMC agent on the SiteScope machine, so we will be able to use the api dll). With the API, we build the BMC Patrol hierarchy and present it in BAC. The component in BAC that activates this process is the adapters (CMDB -> sources).

· The pdf mentions that It is recommended not to install a SiteScope with many configurations and many running monitors on the same machine as the central agent. Why is this not recommended? Is it resource contention? How many is too many? – Yes, this is resource issue. The central agent is an agent that will work quite hard. Therefore, we don’t want it to be installed together with a loaded SiteScope. I don’t know to tell you how many is too many. It is more a general saying which come to show the importance of applying resources to the central agent.

· Will this monitor work against a Unix server that runs BMC? – We don’t have BMC integration if SiteScope itself is installed on UNIX, but we can retrieve information from a BMC agent which is installed on UNIX machine.

· What are the specific settings required to get this working through a firewall? – We have here two ways of communications.

a. One is from the agents to SiteScope (events data). All this is done in BMC Patrol channel. Therefore, we just need connection between all the remote agents to the central agents (which usually listen on port 3181) and the central agent to the SiteScope that has the BMC monitor configured in (listening on default port = 1789).

b. Second is the connection from SiteScope to all the agents in order to retrieve configuration. We need an access from SiteScope which has the monitor configured in to all the agents we need to retrieve configuration to (default port is 3181).

SiteScope 7.9.5.x and greater Troubleshooting

How the monitor Works in 7.9.5.x:

You use the BMC PATROL (Classic) Alert Metrics Monitor to collect measurement data from a BMC PATROL (Classic) Alert database and forward them to Mercury Business Availability Center.

About the BMC PATROL (Classic) Alert Metrics Monitor

Each time the BMC PATROL (Classic) Alert Metrics Monitor runs, it collects the new metrics from a BMC PATROL (Classic) Alert database and sends them to Mercury Business Availability Center as time series data. You can use the configuration file for the BMC PATROL (Classic) Alert Metrics Monitor to control the data that is sent from SiteScope to Business Availability Center.

Setup Requirements

The following are key system requirements for using the BMC PATROL (Classic) Alert Metrics Monitor.

Note: If you are upgrading SiteScope from version 7.8.1.2 or 7.9.0.0, see the note about upgrading Integration monitor types for version 7.9.1.0 or later in the section "Working with SiteScope Integration Monitors"

· You must use one of the database drivers supplied by default, or install or copy a compatible database driver or database access API into the appropriate SiteScope directory location. The supplied drivers include: com.inet.tds.TdsDriver – (TDS driver from i-net Software for Microsoft SQL databases), oracle.jdbc.driver.OracleDriver – (JDBC thin driver for Oracle 7 and 8 databases). Many other database driver packages are available as compressed (zipped) archive files or .jar files. Database drivers in this form must NOT be extracted and must be installed into the /SiteScope/java/lib/ext directory. If you extract drivers from their compressed files (not recommended), the individual driver files must be placed in the /SiteScope/classes directory instead of the java directory.

· You need to know the syntax for the Database Connection URL. The Database Connection URL normally includes the class of driver you are using, some key name relating to the supplier of the driver software, followed by a combination of server, host, and port identifiers. For example, jdbc:inetora:<hostname>:<port>:<dbname> – (where hostname is the name of the host where the database is running, port is the port on which the database interfaces with the driver, and dbname is the name of the Oracle database instance) jdbc:oracle:thin:@hostname:port:dbname – (where hostname is the name of the host where the database is running, port is the port on which the database interfaces with the driver, and dbname is the name of the Oracle database instance)

· The Oracle server that contains the BMC PATROL (Classic) Alert repository you want to query must be running.

· You need a valid username and password to access and perform a query on the database.

Configuring the BMC PATROL (Classic) Alert Metrics Monitor

The BMC PATROL (Classic) Alert Metrics Monitor should be added to a SiteScope monitor group created for this monitor and other Integration monitor types. To add a BMC PATROL (Classic) Alert Metrics Monitor:

1. Click on the monitor group container where you want to add the BMC PATROL (Classic) Alert Metrics Monitor instance.

2. In the Group Contents pane, click the New Monitor button. Alternately, you may right-click the group container in the Enterprise menu and select New Monitor from the Action Menu. The New Monitor selection pane opens.

3.Click to expand the Integration Monitors section on the New SiteScope Monitor panel. The Integration Monitor selection panel opens.

4. Click the BMC PATROL (Classic) Alert Metrics Monitor name. The New Monitor pane for the BMC PATROL (Classic) Alert Metrics Monitor opens.

5. Complete the Main Settings section as described in the following section. Configure other settings as described in the following sections as necessary.

6.Click OK to create the new monitor instance.

Main Settings for the BMC PATROL (Classic) Alert Metrics Monitor

You use the Main Settings section to specify how SiteScope should connect to or check the BMC PATROL (Classic) Alert database for metrics, how often this BMC PATROL (Classic) Alert Metrics Monitor instance should be run, and the text name used for this monitor instance in the this product context interface. Complete the entries in the Main Settings section as described below. Complete the entries as needed and click the Ok button to save the settings.

Name

Enter a text name for this BMC PATROL (Classic) Alert Metrics monitor instance. This text is displayed in the Monitor Administration interface and in the SiteScope interface. If you do not enter a name text, a default name will be used.

Frequency

Select how often the BMC PATROL (Classic) Alert Metrics monitor checks the database for metrics to forward to Mercury Business Availability Center. The default interval is to update once every 10 minutes. The update interval must be a minimum of 15 seconds or longer.

EMS Configuration File Path

Enter the path to the EMS integration configuration file relative to the SiteScope installation. The default location is: \SiteScope\ems\BMC PATROL (Classic) Alert\measurement.config. If you want to edit this file, create a copy on the SiteScope machine and work in the new copy. Then, in Monitor Administration, edit the path to the file.

SELECT

Enter an optional SELECT clause to be used in the SQL query. Enter * for all fields or a comma separated list of column names to be retrieved from the database. The default value for the BMC PATROL (Classic) Alert Metrics Monitor is *.

WHERE

Enter an optional WHERE clause to be used in the SQL query. This is an optional field which allows you to define the select criteria. Leaving it empty will result in retrieving all the rows from the table.

EMS Time Difference

Use this option to account for time differences between the system clock time on the monitored EMS machine and the server where SiteScope is running. This is only needed when the EMS data includes time data and the time data shows that there is a time difference between the EMS machine and the SiteScope server. If the time difference is too great the data may be discarded from Mercury Application Management.

Note: The time difference value only needs to be entered if the difference is greater than one minute. There is no need to synchronize differences of seconds less than one minute.

Troubleshooting the Broadvision Application Server Monitor

How to Troubleshoot the Broadvision Application Server Monitor

Monitor Type: BroadVision

Availability: Windows only

SiteScope Versions: 7.9.5.0 and greater

General category: URL

How it Works:
The SiteScope BroadVision Application Server Monitor allows you to monitor the availability and performance statistics of a BroadVision server. The error and warning thresholds for the monitor can be set on as many as ten BroadVision server performance statistics.

About the BroadVision Application Server Monitor
Use the BroadVision Application Server Monitor to monitor the server performance data for BroadVision servers. You can monitor multiple parameters or counters with a single monitor instance. This allows you to watch server loading for performance, availability, and capacity planning. Create a separate monitor instance for each BroadVision server in your environment.

You will need to know the Object Request Broker (ORB) port number for the BroadVision server you are trying to monitor.

In a BroadVision "Production" style environment where there is one primary root server and other secondary servers (for example, Interaction Manager node) on different machines, you can only define a monitor against the primary root node. Metrics for the other nodes in the configuration will be available for selection during root node monitor definition. In other words, monitoring is always accomplished through the primary root node, for all servers.

How to Troubleshoot:

· Telnet outside of SiteScope to the BroadVision server on the appropriate port.

Final notes:
· BroadVision 5.5 and 6.x are both supported

Troubleshooting the CheckPoint Firewall Monitor

How to troubleshoot the CheckPoint Firewall Monitor

How the Monitor Works
The CheckPoint Firewall Monitor uses SNMP to access the Checkpoint host and queries for specific oids listed in the SiteScope\templates.applications\counters.cp file.

How to Troubleshoot

1) Ping server to verify network connectivity. A fully qualified domain name or IP address may need to be specified instead of just a hostname.

2) Walk the CheckPoint Firewall with an outside device (the mg-soft MIB Browser is a good choice) to verify the oids from the counters.cp file are available (this will also verify that the correct community is being used).

3) It is also possible use the SNMP by Mib monitor as an alternative, simply set it up with the MIB’s from the Vendor for the CheckPoint Firewall, and select the counters from the built out tree.