Monitoring scripts are used when the required data cannot be collected through other standard means such as an event or performance counter. A script can be run on a schedule with the output either evaluated for health measurement or collected for reporting and analysis.
|Monitoring scripts can be written in VBScript or JScript in the Operations console. To create a monitoring script with Windows PowerShell, see Scripts Monitors and Rules in the Authoring Guide.|
Monitoring scripts send any output data as a property bag so that it can be used by the rest of the workflow. A property bag is a set of values that each has a different name. Any name can be assigned although it is a best practice to use a descriptive name of the particular value. The monitor or rule that you create for the script includes logic for reading this property bag. For example, you might have a script in a monitor that collects some numeric value. The monitor sets different health states dependent on this value.
Basic Script Structure
A monitoring script in Operations Manager is similar to any other Windows script. It runs on the agent computer and accesses local resources to gather required data. To work correctly in Operations Manager, the monitoring script must perform three distinct actions:
- Create an object for MOM.ScriptAPI.
- Create a property bag and add values to
- Return the property bag.
The following sample shows a monitoring script with the following characteristics.
- Accepts arguments for the name of the
computer that is running the script and a path to the location of
- Creates a property bag with the values named
ComputerName, InstanceName, and PerfValue.
|Visual Basic Script||Copy Code|
sComputerName = WScript.Arguments(0) sApplicationPath = WScript.Arguments(1) Set oAPI = CreateObject("MOM.ScriptAPI") Set oBag = oAPI.CreatePropertyBag() oBag.AddValue "ComputerName", sComputerName oBag.AddValue "InstanceName", "MyInstance" oBag.AddValue "PerfValue", 1.0 oAPI.Return(oBag)
Defining a Script
Scripts in a management pack must be given a name with either a .vbs or .js extension depending on their language. This name is used to create the file in the temporary directory on the agent. There is no requirement to make this name unique because each script is provided its own temporary directory on the agent.
Arguments are provided to the script in a single line separated by spaces. This is identical to the command line that would be provided if the script were run at a command prompt. You can add arguments to the script by clicking the Parameters button.
Each argument can be either an explicit value or a $Target variable that refers to the value of a property on the target object. Any $Target variables are resolved when the script is run so that the script is provided with the resolved values at the command prompt. You can use $Target variables by clicking the Target button and then selecting one of the properties. The properties that are available will be those from the type of object that you selected for the target of the monitor or rule.
|Any $Target variable that might resolve to a value that includes a space should be enclosed with quotation marks. If a value includes spaces and does not have quotation marks, the script interprets it as two separate arguments. The quotation marks ensure that the value is interpreted as a single argument.|
For example, the sample script earlier expects two
arguments, one for the computer name and one for the application
path. Assuming this was part of a monitor or rule targeted at a
class hosted by the
Windows Computer class, the
computer name could be retrieved from the
PrincipalName property. If the application path were a
property on the targeted class, then the arguments might look
similar to the following example. Notice the quotation marks around
ApplicationPath property, because this could
resolve to a value that contains a space.
|Visual Basic Script||Copy Code|
Script Timeout Value
All scripts are given a timeout value which indicates the number of seconds that the script can run before the agent stops it. This prevents problem scripts from running continuously and putting excess overhead on the agent computer.
The timeout value assigned to a script should allow enough time for the script to run under ordinary conditions, but should be less than the interval that the script is scheduled to run. If a script is configured to have a timeout value greater than its duration, possibly multiple copies of the script could be running concurrently.
For More Information
See Scripts Monitors and Rules in the Operations Guide.