Parameter guidelines

This section summarizes the general considerations involved in defining PATROL parameters.

Why create a parameter?

Create a parameter to do the following:

Monitor any aspect of a resource and alarm when a serious condition occurs.
Perform routine tasks automatically or trigger batch processing at a scheduled time or when certain criteria are met.
Automate problem recovery.
Store collected data for trend analysis.
Start and stop other parameters.

In developing parameters for a monitored object, consider all internal and external resources used by the managed object.

How to create a parameter?

When you create a parameter to monitor an application, you may want to do the following things:

Required actions
- Define each standard or consumer parameter's display style (graph, gauge, text, stoplight, Boolean state, or no output), add a title and denote the units of parameter's value.
- Set each standard or collector parameter's data collection schedule (polling cycle or event-trigger).
Optional actions
- Set each standard or consumer parameter's alarm ranges to notify you of a problem by defining a numeric range within which the parameter value must remain during normal object operation or for optimal performance. (OK range)
- Define commands to perform certain routine tasks triggered by a specific condition.
- Define a recovery action that automatically executes when a certain problem occurs.
- Add an environment variable (for example, a directory path) for a parameter that either overrides or appends to the environment variables defined for an object class (for example, one that is more specific than the path for the application class).
- Define different versions of a parameter for each operating system, for each command type, or for different environments.

General guidelines

PATROL KMs are intended to monitor and manage a large number of systems using few resources. In meeting this goal, the most efficient method is to use collector-consumer parameter pairs whenever possible.
Although peripheral or early warning parameters should not be ignored, it may be necessary to display this additional information only under exception conditions. Whenever possible, reduce the amount of data presented by PATROL parameters by using the following guideline.

Tip

A parameter is most useful when there is only one cause for its warning or alarm condition.

Parameters that follow this guideline efficiently convey meaningful information to the user and provide a clear recovery path whenever a warning or alarm occurs.

Parameter naming conventions

BMC Software recommends that you use a consistent naming scheme for all PATROL KM objects that you create. This avoids problems with duplicate object names and clearly identifies and associates your PATROL KM components.

Use the following conventions in creating parameter names.

General naming guidelines

No spaces are allowed in parameter names. This convention is enforced by the PATROL product.
Make names meaningful and groupable.
For readability, make the name as short as possible.
Use a common prefix for all the components of your KM; this uniquely associates all the parts of your KM.

Parameter name formation

Use the following parameter naming conventions to facilitate code readability:

Parameter naming conventions

Object

Naming convention

Example

Collector parameter

A collector parameter name is often formed by adding a suffix to the root collector name. It has the following format: parameter_name+coll_suffix

parameter_name is made up of concatenated word(s) that describe the collector (each word with an initial capital letter).
coll_suffix is always the word, "Coll," to denote that the parameter is a collector. The suffix always begins with a capital letter for readability.

FTPFilesColl

Parameter alarm guidelines

Use the following guidelines in setting up parameter alarms, warnings, and border alerts.

Each parameter should have a Border range set, especially if Alarm1 and Alarm2 ranges are enabled.
For a parameter for which the default 0-to-100 range is not correct, you should reset its Range Limits values and possibly activate the Auto Scale feature on the parameter's Parameter Alarm Properties.