Table of Contents
A Target is an individual measurement or test. Targets are used by graphs, alarms and trackers. Each alarm is a target, each item on a graph is a target, each device tracked does so using a target. Targets will use one of the five Data Acquisition methods (SNMP, PerfMon, Script, Remote Script/Module) to get their results.
Each target has an 'Active Refresh Rate' and a 'Timeout'. The 'Active Refresh Rate' is how often the test or measurement is performed. This is in milliseconds. The lower the Refresh Rate the more often a test is performed. A Refresh Rate of 500ms means that a test/measurement is done twice every second. The Timeout is how long the system will wait for a result from the target before aborting the current test/measurement. The PerfMon data acquisition method does not support a Timeout, all others do.
Targets of the same type and host can be grouped together for efficiency. This group of targets will have one 'Primary Target', and all others will be 'Secondary Targets'. The Refresh Rate and Timeout of all grouped targets is set to that of the Primary Target. If the Primary target is deleted Net-Probe will select one of the Secondaries to become the Primary in its place. This will happen transparently to the user. Grouping of Targets can be done after they have been setup individually, as well as at the time of creation.
An Aquirer is either a Target or a group of Targets. So each Aquirer can have one or many targets, but only one Primary Target, one Refresh Rate, one Timeout, and usually makes the test/measurement on one host.
An Aquirer is one of the following types:
Normally you would not add a Target and then create a graph, but rather create a graph using the 'Add Graph Wizard'. This will guide you through the creating of the Targets. The same applies to alarms. The exception is the options on the Properties window toolbar. Here Targets can be added to already created graphs, or an alarm target added to a host.
Each type of Aquirer has its own settings. Some settings are common to all:
For alarms the Target Name is the name of the alarm. For graphs that target name is the name of one of the lines/bars on the graph.
This type of Aquirer accesses information on Microsoft Operating Systems from Windows NT4 up. A request is made to a host for a specific bit of information. One PerfMon Aquirer can ask a single host for any number of bits of information. For each bit of information requested a target is required.
The bit of information requested is made of three components, the Object, Counter and Instance. An example would be 'Processor', '%User Time' and '_Total' respectively. You do not need to know this information, Net-Probe offers lists, allowing you to select the 'Object' of interest, followed by the 'Counter' and the 'Instance' applicable to the 'Object'.
You can obtain information on any computer/server accessible from your 'neighbourhood network', but the computer you are attempting to read the counter from will need to have the correct permissions to allow you access. The user that is running Net-Probe will have to have access to the counter. If you are using the Net-Probe Service then the account the service is running under will have to be given access on the remote computer.
Settings required by PerfMon:
Simple Network Management Protocol (SNMP) is an extremely powerful method of obtaining information about a device. Almost all routers support this protocol. Microsoft server Operating systems include support for this protocol. Unix operating systems can use the NETSNMP open source package to support this protocol. A complete description of the protocol is beyond the scope of this manual. It will however attempt to offer enough to get the novice started.
To access the data offered by devices supporting the SNMP protocol, two bits of information are essential. The first is the host name or IP Address of the device. The second is the community. This can be thought of as a password. SNMP devices will only respond to SNMP requests if the community sent in the request matches the community set on the device.
So to Net-Probe a request to a device, that has a functioning SNMP service, with the incorrect community specified, will appear as though the device does not exist or the service is not responding.
There is one other bit of information required in the request, that is the OID or OBJECT IDENTIFIER. This specifies what information the SNMP devices must deliver. In all cases Net-Probe will allow you to select the item desired through a SNMP browser, which will list all OIDs/MIBs the community is delivering.
Most SNMP devices have a default community of 'public'. The amount of data displayed for this community is also usually limited, more sensitive information is usually only presented to a different community. If you are unsure what community to use try 'public' as a start, if this fails check the SNMP settings of the device to obtain the correct one.
A SNMP Aquirer can have any number of OID requests but they must be to the same host and have the same community. If data from a different community needs to be accessed or data from a different host is required, a separate SNMP Aquirer would have to be set up.
Settings required by SNMP:
Also See: the section called “SNMP Browser”
The Script Aquirer executes a script function with a predefined set of input parameters. The output of the function is evaluated to get the reply value used for graph measurement or alarm test. Up to 6 different input parameters and 9 different output values can be utilized per script.
You will not need knowledge of how the pre-written scripts work in order to use them. Tags within the script allows the setup to be very intuitive and the setup wizards, in many cases, fills in the information required for the script for you. Most pre-written scripts can be used for both alarms and graphs, but some of the scripts are only supported with graphs or alarms. The wizard will once again restrict the selection to those that are applicable.
There are a lots of standard services used on most networks, like SMTP (Simple Mail Transfer Protocol) and others. For these Net-Probe has pre-written scripts. But there will be networks that deploy specialized services. For Net-Probe to only offer a closed set of tests without any expandability, would make it useless under these more specialized situations. But as all the pre-written scripts are open, they can be viewed, modified and expanded. This allows for incredible flexibility. If your specialized service can be interfaced with, in any scripting language then Net-Probe will be able to measure and test it, with very little scripting skills.
When adding a new script target you will be given two choices. Either to select from one of the pre-written scripts, or to select a script by browsing the file system. In this section we will cover how to use the pre-written scripts. Before the scripts are listed you will be asked if you would like some basic testing to be performed on the scripts. This will determine if the script is capable of working given your computers configuration and, if the test fails, it will not allow it to be selected. If, for example, you select a Perl script, but Perl is not installed on the computer, then by not allowing the script to be selected, would encourage you to choose the VB-Script equivalent. The next step would be to select the 'Return Argument'. A drop down list will be presented showing the options available. The host to be queried may be required (in some cases it will be known depending on how the Wizard was started). For most internet related tests the Host is required and should be entered. This is the computer that will be tested. The remaining entries revolve around selecting the input parameters.
Pre-written scripts will display text indicating what is expected for each input parameter, i.e. host, username, password etc. If the system has filled in <Host> or <Timeout> then leave these in place, unless you want to deviate from the general entries of the target. In other words, <Host> and <Timeout> as input parameters, will be replaced by Net-Probe before execution with the Host and Timeout specified in the target. If a parameter is not required by a script it will be blocked out. If a parameter is optional, as with say FTP, then you can select to add the parameters. In this case the ftp check can test to see if the the FTP service responded correctly without a username and password. But depending on how thoroughly you wish to test the service you may elect to enter the username and password and test if the service does, in fact, allow the user to log onto the server. Some parameters will not be optional, as with say DNS, here at least a domain name is required for testing. The Wizards will not allow you to continue unless you enter these. There will be an * at the end of the text indicator for non optional arguments.
The pre-witten scripts will return one of three values plus a text string. The values are as follows:
'OK' means the test went ok. It may be followed by a description of how the service responded. 'Warning' responses indicate something was not as expected, but the problem was most lightly not failure of the service itself, but rather some supporting service, an example would be if a host name could not be resolved for a FTP test. 'Critical' means the test failed. A lot of the pre-written scripts will also return a third value and that is the time taken for the service to respond. These are in milliseconds. Once again the wizard takes any guess work away by offering a text description of the output, and only showing output that is applicable (it will not show output suitable for an alarm if you are creating a graph, and visa versa).
The output of the script is put into the read only property called 'Info'. Appended to the end of the output should be a value in <>. This is the value that was obtained from the output depending on the 'Return Argument' specified.
A script may not run for many reasons. The script itself may be faulty, the script may require a component that you have not yet installed, etc. A script failure could be detected when Net-Probe loads and prepares to run the script. This type of failure is usually caused by a missing module or a syntax error and will often (but not always) be detected by the basic test offered in the wizards. Net-Probe will not re-attempt to run these scripts as it knows there is no chance it can work. The Aquirer will start and stop. The 'Aquirer Status' under the properties will show 'Stopped'. If one of the pre-written scripts were to give this result it would most lightly be as a result of a missing module (especially in the case of a Perl Script). Looking through the logs may offer more info about these problems. There will be an entry in the logs offering information as to why the script did not start.
Settings required by Script:
If the script contains tags (as with all pre-written scripts) then the settings required will be better defined than that above. You will have descriptions for input and output parameters, and be limited to what is applicable.
Also See: Chapter 22, Writing your own Scripts
Remote scripts aare very similar to normal scripts except that the 'remote computer', that will be executing the script, needs to specified. For Remote-Scripts to work, software needs to be installed on the remote computer. The software is called "Remote-Probe.pl' and is bundled with Net-Probe. You then setup your Remote Script Target in very much the same way you would the normal Scripts, but at a point you will be asked to specify the remote computer. If the 'Remote-Probe.pl' has been setup correctly then the remote hosts IP should appear as an option already in the 'Remote Host' box.
Net-Probe will then pass the script specified to 'Remote-Probe.pl' on the remote computer, with the Refresh Rate, Timeout and the Script Language. 'Remote-Probe.pl' then executes the script and sends it's output back to Net-Probe, which then evaluates it and does whatever is required.
Since the script is executed on the remote host, the choice of script should depend on the abilities of the remote computer, and not the computer running Net-Probe. If the remote computer is a Linux box with Perl installed then send a Perl script to the remote box, sending a VB-Script will most definitely fail.
When setting up a Remote-Script you will not be offered the 'Perform Basic Test' option found in the Script Wizards. This can only perform the test on the local computer, and not the remote computer. A failure on the local computer (the computer with Net-Probe installed) does not mean that it will fail on the remote computer, and visa versa.
Settings required by Remote Script:
If the script contains tags (as with all pre-written scripts) then the settings required will be better defined than that above. There will be descriptions for input and output parameters, and will be limited to what is applicable.
|Copyright (c) Warren Flemmer 2006||www.net-probe.com|