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:
a passive check result to Opsview Monitor with an appropriate message, or
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
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 Monitor. However, there will only ever be one SNMP
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
Note: Traps received will have the SNMP
community value hidden so that passwords are not stored on the file system.