Service Response Monitor › Test Management › Using Custom Scripts to Create Tests

Using Custom Scripts to Create Tests

You can create a custom script to instruct SRM to perform a custom test on a local system.

Guidelines for Creating Custom Tests

Consider the following when creating custom tests:

• If a custom test returns a value <= 0 for name resolution time, connection time, or transaction time, the test availability is set to 0.
• The unit for times reported by a custom script is milliseconds.
• A successful custom script needs to return integer values only.
• A successful script returns 0 as its exit code. A value other than 0 represents a failed custom script.
• The result code is placed in the results field in the MIB for that test.

Guidelines for Writing the Script

You can write the script as a binary executable or in a scripting language such as UNIX shell or Perl. Custom response modules work very much like SystemEDGE agent extension objects. For more information about SystemEDGE extension objects, see the SystemEDGE User Guide. SRM expects the custom script to provide a single line of output with at least three values (and up to six values) followed by a line feed.

The script you create must return the following information in this order:

1. DNS resolution time (required)
2. Connection time (required)
3. Transaction time (required)
4. Result code (optional)
5. Bytes in (optional)
6. Bytes out (optional)

SRM calculates throughput based out on the data the script returns for bytes in and bytes out. Therefore, if the script provides bytes in, it must also provide bytes out (and vice versa). Correct output from the script must be one of the following three options:

Option A:

1. DNS resolution time
2. Connection time
3. Transaction time

Option B:

1. DNS resolution time
2. Connection time
3. Transaction time
4. Result code

Option C:

1. DNS resolution time
2. Connection time
3. Transaction time
4. Result code
5. Bytes in
6. Bytes out

Options and Arguments

Custom tests require the following specific option or argument:

Script Path – The full path and file name to the custom script that you want to run.

Note: When you are specifying pathnames, be sure to use the correct type of slashes for the operating system on which the test runs, that is, use forward slashes (/) when you specify directories for tests that you intend to run on UNIX systems and backslashes (\) when you specify directories for tests that you intend to run on Windows systems.

When you specify the timeout value for Custom tests, ensure that it provides enough time to allow the script to execute. If the script does not have enough time to execute, SRM will terminate it, and if the script does not clean up its own child processes, those processes continue to run, which could eventually cause the system to hang.

You specify this option or argument when you create or modify tests.

Example

Use this example to create a test that monitors the amount of time that is required to run the script located in /local/bin/custom_Test.pl. The entry instructs the agent to test the service once every 120 seconds (2 minutes), and to wait up to 20 seconds for a successful response. The agent calculates statistics over the last 3600 seconds (6 hours).

Do the following on the Create a new Test page

1. Select Advanced next to Common Options.
2. From the Test Type list, select Custom.
3. In the Test Name field, specify custom_Test.pl.
4. In the Description field, specify Test Custom Service.
5. In the Test Interval field, specify 120.
6. In the Test Timeout field, specify 20.
7. In the Samples Per Interval field, specify 1.
8. In the Statistics Window field, specify 3600.
9. In the Script Path field, specify /local/bin/custom_Test.pl.
10. Click Save Test.

When you commit your changes, SRM adds an entry similar to the following to the svcrsp.cf file:

{ 
index=99 
type=custom
desc="Test custom service" 
dest="/local/bin/custom_Test.pl" 
interval=120 
samples=1 
timeout=20 
window=3600 
tos=0 
limit=0 
status=active 
name="Custom Service Test"
class=""
context=""
flags="1"
loglevel=1
}

For information about errors you may encounter when running custom tests, see Custom Test Error Codes.