Occasionally you will come across a device or a situation where collecting a single SNMP variable is insufficient, for example when two or more SNMP properties need to be combined to provide a meaningful measurement.
NMIS version 8.4.8G and later support modelling such scenarios using custom variables, or
CVARs. With this mechanism you can temporarily capture up to 10 separate SNMP properties as a
CVAR and define an arbitrarily complex expression (in perl) that transforms these
CVARs into the one measurement that you want to collect and/or display.
Where and How to use CVARs
CVARs are supported
- in the
valueexpressions in the NMIS alert and threshold subsystem,
calculateexpressions in the general modelling subsystem,
- and from NMIS version 8.6 on, also in
controlexpressions evereywhere (in versions before that only a single
CVARwas supported in
CVARs you define the required
CVARs as holding a previously specified SNMP variable at the beginning of one of the supported expressions; Subsequently you can then reference the
CVAR value in the part of the expression that calculates the desired value to be used by NMIS.
An example scenario
The DS3 MIB defines a variety or error counters for DS3 circuits like "dsx3CurrentLCVs" which are based on a 15 minute observation interval and reset automatically at the end of the interval. As the interval start and end is arbitrary and up to the device to set, just capturing the error counters themselves is not quite workable. However, the DS3 MIB also specifies the variable "dsx3TimeElapsed" that holds the seconds elapsed since the start of the current observation interval. Dividing the raw error counter by the number of seconds into the interval results in a normalised errors-per-second rate which works well for collection and display.
Here is an excerpt of the relevant model file:
In the example above, the
calculate expressions are used in two ways:
- to transform the bitfield variable "DS3 Line Status" into a more verbose textual list of component statuses,
- and to divide the raw
dsx3CurrentLCVserror count by the
In both cases the syntax is very straight-forward:
- The expression must be a valid perl statement and return exactly one value.
- The tokens
CVAR9are interpreted by NMIS; everything else is perl.
- Defining and using local variables with
myis ok, but don't attempt to change any global NMIS variables.
"CVAR1=some_snmp_var;" defines what SNMP object CVAR1 is supposed to hold. The parser understands
CVAR9for a total of 10 captures.
- You can use functions that were defined elsewhere in NMIS in your
You will likely have to include the full module namespace in the function call, e.g.
Only functions without side-effects should be used.
return $r/$CVAR1;" accesses the value of
CVAR1in an expression. The variable "
$r" represents the SNMP variable that the
calculateexpression is attached to.
Please note that
$CVARn replacement in the expression is performed on a purely textual basis, before the expression is handed to the perl interpreter for evaluation :
For string variables you have to provide quotes in your expression, e.g.
- Numeric variables can be used straight without quotes.
$CVARn access refers to the raw value of the named property, ie. the data before any
calculateexpressions for the named property were evaluated.
How to keep temporary CVAR data out of the RRD databases
As outlined above all the objects that you want to access via
CVARs must be defined in the same section. If your test/calculate expression is within an
rrd section, all the other objects will have to be within that
rrd section, too, and thus they would be collected by NMIS and stored in RRD - quite wasteful if these other variables are just temporary and only there to for access using one
In versions 8.6.0 and above you can prevent this by adding an
option with value
In the example above,
hrNumUsers would be retrieved with SNMP, and other variables could be defined in terms of e.g.
hrNumUsers would not be saved.
Please note that setting
nosave disables alerts for the given object.
Sometimes there is a need to create calculated data using data gathered from several sources and calculated into a single table. Situations such as this might call for use of a plugin (NMIS 9 Collect and Update Plugins). The problem comes in when the model tries to interpret the sections in the model when there is lack of data to do so. This causes errors in the model. To solve this, there is a keyword. 'placeholder' which can be used in the 'sys' section of the model definition to tell the model that the 'headers', labels, and 'titles' only exist to create the necessary infrastructure for the data, and the some other method will be used to create the values. There really isn't much to this, just the keyword 'placeholder', and the value will be printed in the log to say that the <value> will be used to fill in the data as shown in the example below.