...
The alert can be added to current variables being polled from the devices, or a new section can be added. For example a new section in Model->system->sys could be added which might look like this, the the example below (the "--snip--" indicates that extra model code has been removed , this is provided as an example of the context for where to add this to the models.for clarity):
| Code Block |
|---|
%hash = (
--snip--
'system' => {
--snip--
'sys' => {
'standard' => {
--snip--
},
'alerts' => {
'snmp' => {
'tcpCurrEstab' => {
'oid' => 'tcpCurrEstab',
'title' => 'TCP Established Sessions',
'alert' => {
'test' => '$r > 250',
'event' => 'High TCP Connection Count',
'level' => 'Warning'
}
}
}
},
--snip--
}
--snip--
}
--snip--
); |
Adding the alert also adds the information to the "Device Details" panel, so you get the last polled value displayed all the time. Note that when you add such a basic alert its variable is collected independently of any other variables that your model might collect.
Example
The following is an example of the layout of an alert (in this example serialNum is taken from Model-CiscoRouter.nmis) and uses a string based (stringwise) comparison:
...
Alerts can also be created in the 'alerts' section of the model (if the . lerts created in this section have the advantage of being able to use values from a whole section of data to determine if the alert should be triggered or not; however, such alerts can NOT access variables collected/modelled in the 'system' section and as such are mostly useful for systemHealth modelling.
If the model does not have that such an 'alerts' section, it can be added at the lowest outermost level of the model, e.g. along side '-common=' and 'system'. Alerts created in this section have the advantage of being able to use values from a whole section of data to determine if the alert should be triggered or not. A
A concrete example always makes things more clear.
...
Let's break down the above example.
'services' => -- defines what section the values being used for the alert are taken from. In this case services cannot won't be found in the model because it is a special section just for servers. Normally you will not need to worry about special sections.about special sections. Please note that you CANNOT use the 'system' section for advanced alerts!
'HighProcessMemoryUsage' => { – – this creates a label/id for the alert
'type' => 'test' – – this means the alert will test a single condition. The options are ['test', 'threshold-rising', 'threshold-falling']
'test' => 'CVAR1=hrSWRunPerfMem;$CVAR1 > 300000', – – defines a custom variable and then uses that variable to perform a boolean test. NOTE NOTE: in test mode only one custom variable can be used
'value' => 'CVAR1=hrSWRunPerfMem;$CVAR1 * 1', – – the value triggered the alert and that will be displayed when the alert is shown in the GUI
'unit' => 'KBytes', – – the unit that the above value will be displayed with
'element' => 'hrSWRunName', – which OID/value that has the problem, a descriptor or identifier. In this case it is showing the name of the process that has high memory usage.
'event' => 'High Process Memory Usage', – the name of the event
'level' => 'Warning' – the level the event will be triggered as. When using thresholding this is not used as the threshold defines the level
Thresholds
While boolean tests are nice it is often much more useful to specify levels of acceptance instead of just on or off, thresholds allow us to do this. Another example:
...