Considerations for writing a script

This topic provides information about the considerations to take into account while writing a script.

How to write scripts

This video is part 1 of a deep dive into how to effectively use this KM. It provides an overview of how to create scripts, the different options available to you, and how to ensure that the scripts are valid.

 https://youtu.be/zTPdAblZJE4

Considerations

• How many instances do you need - Do you need to create one or multiple instances while running the script?
• How many parameters will you require - Is there a need for a single parameter assigned with a value or do you need a set of parameters, each parameter with a different name and value?
• Does your script have all the required details - Do you need to provide the script with arguments from the policy details or does your script has all the details?
• What is the intent of the script - Will the script be used for monitoring the server on which the PATROL Agent is running or will your script run on multiple remote hosts and report data to the PATROL Agent?
• Is the script required - Do you need to to write a script for the required output or is it possible to get the same result using a single (sometimes long) one line command?

Ensure that script runs properly before deploying it on the PATROL Agent or KM for execution. The script should operate from command line in the same manner as it would operate from the KM.

If possible, BMC recommends to write a script on a computer that is similar to the monitored computer. Store your scripts in the /tmp folder for easy access of all users of the system. In general, a script uses a core tool to extract data. The next part is to format the text and send it to the KM in an acceptable manner.

Sample scripts for Linux

The KM provides some built-in scripts that can help you manipulate text data. The following sample scripts are provided:

Recommendations

After the script is ready, test it. BMC recommends that you run the following tests:

• Ensure that the script generates unique parameter names. The script must not generate two parameters with the same string as a name.
• When running the script with invalid set of arguments, it should still issue a valid output. An output that can be consumed by the KM.

• The script does not over use resources: CPU, HDD, NETWORK, MEMORY. 

  Note

  A script that creates temporary files should also be able to remove the temporary files.

• The script can run with the existing shell. For example, BSH versus KSH versus BASH versus CSH and so on. A script cannot run as a BASH script on a system, where BASH does not exist.
• Script execution is expected to end early than the polling cycle of the policy. You cannot use a script that runs for two minutes on a policy that is scheduled to run every minute. 
• Ensure that a script reporting a single value and multiple line annotation uses the data annotations in a proper manner. Your script must not set data point annotation of 0.5 MB of text. Size of annotation must not exceed 32 KB.
• A script might be generated on a single test machine, but must be capable of running on multiple machines of different types. Ensure that the script can run on all flavors of UNIX and Linux and the targeted versions. For example, the operating system utility df, can be used within a script that monitors the level of usage per file system. However df is used differently across AIX, LINUX and other flavors. Hence, using a unified script will not work. Your script must be able to check the operating system type and version and react accordingly.
• PATROL for Scripting KM cannot handle interactive negotiation with the script. For example, The monitoring will fail if the script calls a tool which prompts for a password. Ensure that the script can execute in offline mode.

Sample scripts for Windows

The KM provides some built-in scripts that can help you manipulate text data. The following sample scripts are provided:

Recommendations

After the script is ready, test it. BMC recommends that you run the following tests:

• Ensure that the script generates unique parameter names. The script must not generate two parameters with the same string as a name.
• When running the script with invalid set of arguments, it should still issue a valid output. An output that can be consumed by the KM.

• The script does not over use resources: CPU, HDD, NETWORK, MEMORY. 

  Note

  A script that creates temporary files should also be able to remove the temporary files.

• The script can be .bat, .exe, .ps1, perl, python and so on.

• To access the PowerShell script from a remote device for execution, the Set-ExecutionPolicy RemoteSigned permission should be set.

How to run non PowerShell scripts

To run a non PowerShell Script, you have to modify runtimeExtensions.properties file present at %PATROL_HOME%/TROMS/Conf/Properties. This properties file helps you to convert a non powershell script to execute on PowerShell. 

For example: In Powershell, if you want to run .pl (perl) file, you need to add the word perl at the starting of the script. But by modifying the runtimeExtensions.properties file, you can execute the script as is (the file appends perl automatically).