Still a work in progress...
| Table of Contents |
|---|
Consider a situation that our operator would like to be aware of before customers begin complaining. It is with these situations in mind we should consider provisioning thresholding in NMIS.
Related Information
Basic and Advanced Thresholds in NMIS8
Provisioning Thresholding
Thresholding can be accomplished with the following steps:
...
#3. Add statistics extraction to Common-stats.nmis
Testing Thresholds
After provisioning a threshold it is important to verify it is working as intended. Run the threshold manually as below.
| Code Block |
|---|
usr/local/nmis8/bin/nmis.pl type=threshold debug=true
### Look for output similar to the following that displays the current value and the threshold value.
22:27:36 getThresholdLevel, Start theshold=ssCpuRawUser, index=
22:27:36 getThresholdLevel, found threshold=ssCpuRawUser entry=default
22:27:36 getThresholdLevel, threshold=ssCpuRawUser, item=ssCpuRawUser, value=2.15
22:27:36 getThresholdLevel, result threshold=ssCpuRawUser, level=Normal, value=2.15, thrvalue=60, reset=60
### Change the threshold level to a value below the current value.
### This should cause the threshold policy to fire an alert.
### Common-thresholds.nmis
'ssCpuRawUser' => {
'item' => 'ssCpuRawUser',
'event' => 'Proactive CPU User',
'select' => {
'default' => {
'value' => {
'fatal' => '90',
'critical' => '80',
'major' => '70',
'minor' => '65',
'warning' => '1',
}
}
}
},
##############################
### In order to test with the new threshold a nmis update must be executed.
### From the bash prompt:
/usr/local/nmis8/bin/nmis.pl type=update
/usr/local/nmis8/bin/nmis/pl type=threshold debug=true
### Now look for the corresponding threshold policy in the debug output.
22:43:59 getThresholdLevel, Start theshold=ssCpuRawUser, index=
22:43:59 getThresholdLevel, found threshold=ssCpuRawUser entry=default
22:43:59 getThresholdLevel, threshold=ssCpuRawUser, item=ssCpuRawUser, value=2.18
22:43:59 getThresholdLevel, result threshold=ssCpuRawUser, level=Warning, value=2.18, thrvalue=1, reset=0
22:43:59 thresholdProcess, Proactive CPU User, Warning, , value=2.18 reset=0 |
Log into the GUI and notice the alert present in the NMIS event log.
Thresholds used to drive event reporting can be created based on any measurable attribute. In this example we'll cover something in the systemHealth section.
Files
Files that require modification:
- /usr/local/nmis8/models/Model-Some-switch.nmis
- /usr/local/nmis8/models/Common-database.nmis
- /usr/local/nmis8/models/Common-header.nmis
- /usr/local/nmis8/models/Common-stats.nmis
- /usr/local/mmis8/models/Common-threshold.nmis
Relationship of the files to each other
It may be useful to visualize how the files interact with each other.
Common Attributes
There are several common attributes that must match between these files in order for thresholding to work. In an attempt to demonstrate the relationship between these variables we'll use the following labels. Please reference the code block below for where they should reside.
...
echo - This variable is set in the Common-stats.nmis file. It is used to make computations on the zebra variable in the RRD language. This variable is then passed to the Common-threshold.nmis file in order to fire and event.
