| Table of Contents |
|---|
Escalations
Configuring escalations in NMIS8 happens in two locations. The first location is in System -> System Configuration -> NMIS Configuration area (escalation in the drop down) which stores it's its settings in Config.nmis. This is where the escalation levels are located. An escalation level links an elapsed amount of time to a name. For example, by default escalate0 happens immediately (0 seconds) escalate1 happens after 300 seconds, and so on. The names and times are configurable.
...
The different levels are described above but they are really a very straight forward mapping of elapsed time to a string key. Here is what they look like by default:
Escalations / Table of Escalations
...
This is where things get more interesting. First I will show you the default escalation table that ships with NMIS8, then we will look at it more closely to understand what it is doing.
The entries this in this table define notification details for an event: who to notify, how to notify them and when that notification should happen. Any matching line will cause the escalations in that line to be applied. When a column is set as default, any value for that column is considered matching. Let's take a look at the first line which matches all events:
Each of the values for Group, Role, Type and Event are set to default. This This means any event that happens in any group in any role of any type will trigger this event. This is a catch-all event, if your network is small and there is a low number of events this could be all you need, if your network is large and creates a lot of events this may end up being useless.
...
Rules can be narrow or wide depending on what groups, roles, device type and event values are given. You can also set a node (or device) name so the rule applies to a specific node, or an Event Element which is an interface. NOTE: the element string in the escalation table will match on any part of the event's element string.
Notification syntax
There are 6 types of notifications that can be added: syslog, json, email, ccopy, pager and netsend.
...
- When UpNotify is "true", for any "down" message which is sent an UP notification will be sent when the node or element comes up, then lets you know the event is "resolved".
- When set to "false", no notification will be sent when the node or element comes up.
Preventing Escalation/Notification Storms using the NMIS Node Depend Feature
Consider a situation where an edge router goes down, and from the perception of NMIS all the nodes behind it appear to be down. By default nmis would send escalation emails for all the nodes behind the edge router. In order to only have NMIS send the escalation email for the edge router and not the nodes behind it, the 'depend' attribute can be set on the nodes behind the edge router. Setting the depend value to the edge router for the nodes behind it will prevent excess escalation emails.
Consider the above topology. If bnelab-rr1 goes down, we don't want escalation emails from the other six nodes. For each of the other 6 nodes we would edit the depend attribute to contain the value of bnelab-rr1.
Notice that via the GUI edit node context you can select multiple nodes for the depend value. This may be advantageous if the site has redundant edge routers.