What are SNMP Traps?
With SNMP Polling, the Network Management Station (NMS), Opsview, is required to poll various objects for information, on various devices. This could take a large amount of time to configure and fine tune and also in the very large environments use a large amount of computing power.
The alternative is called 'SNMP Traps'. With SNMP Traps, instead of the router (for example) being polled for information on a regular basis by Opsview, the router itself will let Opsview know of any problems or issues via a 'trap'.
SNMP Traps vs SNMP Polling
The above illustration shows how an Opsview server will regularly poll a host for information, whether there is a problem on that Host or not. In the example below it, the Opsview is sitting 'listening' for SNMP Traps; when the Host encounters an issue then a trap will be sent to tell Opsview, which in turn will change a Service Check to the state of 'CRITICAL' or 'WARNING' based on the rules you define.
Devices can usually be configured to send specific types of trap such as link status changes, BGP, HSRP, and many others, making this a flexible monitoring option.
From the device perspective, the traps can usually be configured to send a trap to a maximum of two devices at a time. When received by Opsview it will be passed through a perl-based rules engine, allowing you to match specific traps from devices and generate appropriate alerts. In order to do this, SNMP Traps must be passed from the device into Opsview via an SNMP Trap Collector.
SNMP Trap Initial Setup
See SNMP Traps Collector for details on the SNMP Trap Collector.
See MIBs for SNMP Traps and Gets to add your MIBs that are required for translating SNMP Traps.
SNMP Traps Within Opsview
Each Service Check configured to accept SNMP traps has an ordered list of rules. Each rule is evaluated in turn. If a rule is false, then the next rule is evaluated. If a rule matches as true, the specified action is taken and no more rules for that Service Check are evaluated.
An action could be either:
- submit a passive check result to Opsview with an appropriate message, or
- do nothing, and thus stop processing of any further rules
If the incoming trap does not evaluate to true for any rules, then it becomes an exception and will appear on the SNMP Trap Exceptions page. This is required so that an administrator is aware that the rules need tuning to cater for this particular trap.
When a trap is received, it contains information about the source IP. This is associated to a Host. A Host can have more than one SNMP trap service check defined. In this case, each Service Check is evaluated independently of the others. The illustration below shows a trap being evaluated in four Service Checks, represented as columns.
These columns are not ordered, so there is no guarantee which Service Check column will be evaluated first. A consequence of multiple Service Checks is that a single trap could raise multiple alerts to Opsview. However, there will only ever be one SNMP Trap Exception per trap.
One example of using multiple Service Checks is if you wanted a Service Check to show interface status, with another Service Check alerting on error log messages.
Note: Traps received will have the SNMP community value hidden so that passwords are not stored on the file system.
