PATROL parameters

While application discovery tests the existence and general status of a monitored object, a PATROL parameter audits its operational and performance details. Parameters are the basic unit of PATROL KM monitoring. This section reviews parameter concepts as they apply to PATROL KM development.

The PATROL parameter

The term, PATROL parameter, has a special meaning, a PATROL parameter is a procedure (command script) that periodically is executed by the PATROL Agent to obtain and process data about a particular aspect of a monitored object. Parameters can be created to audit any quantifiable attribute, aspect, or metric of an application class or computer class. Parameter data is collected, summarized, and stored on the computer running the PATROL Agent. Parameter data can be accessed by a PATROL Console or an SNMP console.

You can create parameters and assign them to one of the following:

• Computer classes
• Application classes

How parameters work

Parameter command scripts are read and loaded by the PATROL Agent during agent initialization. If they are part of pre-loaded PATROL KMs, parameter execution scheduling begins immediately according to each parameter's scheduling method and settings. The PATROL Agent scheduler maintains the execution schedule for the parameters in the run queue. The scheduler executes each parameter as close to its poll time as possible, while maintaining a manageable system load.

Parameter information and history is stored on the PATROL Agent. When a user "opens" a parameter to view its values, the data is fetched from the agent.

Parameter types

In the PATROL product, there are three basic parameter types - standard, collector, and consumer - and two additional variants of the standard parameter type. Parameter types differ in the way that they gather and display data.

The following table shows the characteristics of each parameter type and compares them.

Parameter types and usage 

Parameter display styles

As summarized in the following table, the PATROL product offers six basic styles to display parameter data. 

Parameter display style summary

Easily interpreted by users

Display style required for the PATROL "annotated datapoints" feature.|

Textual data cannot be used to trigger warnings and alarms.|

Parameter state changes

A PATROL parameter can have various states to indicate its condition. The following figure depicts the standard state model for PATROL parameters. The parameter icons are shown as they appear on the PATROL Console for Windows and UNIX. 

 Parameter state model, Windows and UNIX 

Parameter states, Windows and UNIX

The PATROL product implements a basic four-state paradigm - VOID, OK, WARN, ALARM. However, the PATROL product provides a settleable icon and label built-in substitution macro variable for icons that which allows you to visually simulate any number of object states. You can change object icon color, change its label, or completely change the icon's appearance to indicate the detected object state.

Parameter scheduling

Scheduling controls how frequently the parameter is executed. Because scheduling determines the amount of data a parameter produces, the end-user may need to change parameter scheduling as part of tuning the PATROL KM in his or her environment. 
The PATROL product offers two methods to schedule parameter execution:

• Periodic scheduling starts a parameter at a specific time and reruns the parameter at intervals. Scheduling is set up through the parameter's scheduling properties. In periodic scheduling, the parameter script executes for a short time, then terminates until the next poll time.
• Event-driven scheduling starts a parameter when specific conditions occur. Scheduling is explicitly set up by including conditional logic in the parameter's command script.

The following table describes the available parameter scheduling methods and their usage. 

 Parameter scheduling summary 

How parameter alarms work

For each PATROL Standard and Consumer parameter, you can use three options to set up and define the values of parameter warnings and alarms. Because the Border, Alarm1, and Alarm2 options work together to provide monitoring coverage, you can configure them in several different ways to meet your monitoring needs. Not only do warnings, alarms, and border actions provide monitoring, they also are the triggers for parameter recovery actions.

Range limits

Use the Range Limits option to delineate the entire spectrum of possible parameter values. The Range Limit that you define controls the maximum and minimum values possible for the Alarm1, Alarm2, and Border options.

Alarm1 and Alarm2

Use the Alarm1 and Alarm2 options to define the range of parameter values that trigger warnings and alarms. You can set either option as the warning range or the alarm range, but the Alarm1 range must always have lower values than the Alarm2 range. 
If you wish an alarm to occur when the parameter's value is low, set Alarm1 as the alarm range and Alarm2 as the warning range. If you wish an alarm to occur when the parameter's value is high, set up Alarm2 as the alarm range and Alarm1 as the warning range.

Border

Use the Border option to do the following:

• Define an "out-of-range" alarm condition
• Set up a third-level alarm or warning range

If it i s possible for a parameter to have extreme values that lie near the ends of the range limits, use the Border option to define the range of values that a parameter might have under abnormal conditions. In addition, you can also set up a recovery action associated with a warning or alarm triggered by a border condition. Alternatively, you can use the Border option to set up a third-level parameter alarm or warning range.

Avoid discontinuous range coverage

Set up alarm, warning, and border ranges so that the ranges provide complete monitoring coverage. Internal to the PATROL product, numeric values are floating point. If you set your warning range from 80 to 90 and your alarm range from 91 to 100, a value of 90.4 would evaluate to be "OK" and would trigger no alarm or warning. 
To avoid this situation, you can do one of the following:

• Convert the internal parameter value that is evaluated to an integer by passing it though the PSL integer()
• Set the alarm and border ranges to have a coincident end point

 Choosing an appropriate alarm setup

Use the following table to aid in choosing the appropriate parameter alarm setup.

Setting parameter alarm ranges

 Choosing reasonable alarm ranges

Consider the following things when setting up parameter alarm ranges:

• Can the parameter have values outside the defined range?
  Set up a Border range.
• Should the parameter have more than one warning or alarm?
  Use the Border option to add a third-level alarm or warning range.

 Recovery actions

The PATROL product provides the ability to define automatic recovery actions to correct problems indicated by a parameter's alarm, warning, or border alarms or to take other appropriate actions based on the parameter's value. When a parameter changes state, one or more recovery action command scripts can be queued for execution, each according to its properties settings.

Recovery actions can be set up to execute by increasing strength of action. In addition, you can create recovery actions that determine the corrective action to take based on other parameter values or data available in the PATROL Agent namespace. Recovery actions offer a powerful management tool. 

Parameter recovery actions are executed according to the polling cycle of its parameter, with one recovery action executed per polling cycle. If a parameter has more than one recovery action defined for an alarm condition, the next recovery action executes on the next parameter execution if the parameter remains in the same alarm state. Subsequent recovery actions execute consecutively until the alarm clears or no recovery actions remain.