The directives described in section “Active monitoring” can be used to configure where traps should be sent, but are not concerned with when to send such traps (or what traps should be generated). This is the domain of the Event MIB - developed by the Distributed Management (DisMan) working group of the IETF. The directives are described below:
iquerySecName NAME
agentSecName NAME
specifies the default SNMPv3 user name, to be used when making internal queries to retrieve any necessary information (either for evaluating the monitored expression, or building a notification payload). These internal queries always use SNMPv3, even if normal querying of the agent is done using SNMPv1 or SNMPv2c.
Note that this user must also be explicitly created (createUser) and given appropriate access rights
(e.g. rouser). This directive is purely concerned with defining which user should be used - not with actually setting this user up.
monitor [OPTIONS] NAME EXPRESSION
defines a MIB object to monitor. If the EXPRESSION condition holds (see below), then this will trigger the corresponding event and either send a notification or apply a SET assignment (or both). Note that the event will only be triggered once, when the expression first matches. This monitor entry will not fire again until the monitored condition first becomes false, and then matches again. NAME is an administrative name for this expression, and is used for indexing the mteTriggerTable (and related tables). Note also that such monitors use an internal SNMPv3 request to retrieve the values being monitored (even if normal agent queries typically use SNMPv1 or SNMPv2c). See the iquerySecName token described above.
EXPRESSION
There are three types of monitor expression supported by the Event MIB: existence, Boolean and threshold tests.
OID | ! OID | != OID
defines an existence(0) monitor test. A bare OID specifies a present(0) test, which will fire when (an instance of) the monitored OID is created. An expression of the form ! OID specifies an absent(1) test, which will fire when the monitored OID is detected. An expression of the form != OID specifies a changed(2) test, which will fire whenever the monitored value(s) change. Note that there must be whitespace before the OID token.
OID OP VALUE
defines a Boolean(1) monitor test. OP should be one of the defined comparison operators(!=, ==, <, <=, >, >=) and VALUE should be an integer value to compare against. Note that there must be whitespace around the OP token. A comparison such as OID !=0 will not be handled correctly.
OID MIN MAX [DMIN DMAX]
defines a threshold(2) monitor test. MIN and MAX are integer values, specifying lower and upper thresholds. If the value of the monitored OID falls below the lower threshold (MIN) orrises above the upper threshold (MAX), then the monitor entry will trigger the corresponding event.
Note that the rising threshold event will only be re-armed when the monitored value falls below the lower threshold (MIN). Similarly, the falling threshold event will be rearmed by the upper threshold (MAX).
The optional parameters DMIN and DMAX configure a pair of similar threshold tests, but working with the delta differences between successive sample values.
OPTIONS
There are various options to control the behavior of the monitored expression. These include:
-D
indicates that the expression should be evaluated using delta differences between sample values (rather than the values themselves).
-d OID
-di OID
specifies a discontinuity marker for validating delta differences. A -di object instance will be used exactly as given. A -d object will have the instance subidentifiers from the corresponding (wildcarded) expression object appended. If the -I flag is specified, then there is no difference between these two options.
This option also implies -D.
-e EVENT
specifies the event to be invoked when this monitor entry is triggered. If this | |
-I | indicates that the monitored expression should be applied to the specified OID |
-i OID
-o OID
define additional varbinds to be added to the notification payload when this monitor trigger fires. For a wildcarded expression, the suffix of the matched instance will be added to any OIDs specified using -o, while OIDs specified using -i will be treated as exact instances. If the -I flag is specified, then there is no difference between these two options.
See strictDisman for details of the ordering of notification payloads.
-r FREQUENCY
monitors the given expression every FREQUENCY seconds. By default, the expression will be evaluated every 600s (10 minutes).
-S
indicates that the monitor expression should not be evaluated when the agent | |
-s | |
indicates that the monitor expression should be evaluated when the agent first |
-u SECNAME
specifies a security name to use for scanning the local host, instead of the default iquerySecName. Once again, this user must be explicitly created and given suitable access rights.
notificationEvent ENAME NOTIFICATION [-m] [-i OID | -o OID ]*
defines a notification event named ENAME. This can be triggered from a given monitor entry by specifying the option -e ENAME (see above). NOTIFICATION should be the OID of the NOTIFICATION-TYPE definition for the notification to be generated.
If the -m option is given, the notification payload will include the standard varbinds as specified in the OBJECTS clause of the notification MIB definition. This option must come after the NOTIFICATION OID (and the relevant MIB file must be available and loaded by the agent). Otherwise, these varbinds must be listed explicitly (either here or in the corresponding monitor directive).
The -i OID and -o OID options specify additional varbinds to be appended to the notification payload, after the standard list. If the monitor entry that triggered this event involved a wildcarded expression, the suffix of the matched instance will be added to any OIDs specified using -o, while OIDs specified using -i will be treated as exact instances. If the -I flag was specified to the monitor directive, then there is no difference between these two options.
setEvent ENAME [-I] OID = VALUE
defines a set event named ENAME, assigning the (integer) VALUE to the specified OID. This can be triggered from a given monitor entry by specifying the option -e ENAME (see above).
If the monitor entry that triggered this event involved a wildcarded expression, the suffix of the matched instance will normally be added to the OID. If the -I flag was specified to either of the monitor or setEvent directives, the specified OID will be regarded as an exact single instance.
strictDisman yes
The definition of SNMP notifications states that the varbinds defined in the OBJECT clause should come first (in the order specified), followed by any "extra" varbinds that the notification generator feels might be useful. The most natural approach would be to associate these mandatory varbinds with the notificationEvent entry, and append any varbinds associated with the monitor entry that triggered the notification to the end of this list. This is the default behavior of the Net-SNMP Event MIB implementation.
Unfortunately, the DisMan Event MIB specifications actually state that the triggerrelated varbinds should come first, followed by the event-related ones. This directive can be used to restore this strictly-correct (but inappropriate) behavior.
If no monitor entries specify payload varbinds, then the setting of this directive is irrelevant.
linkUpDownNotifications yes
will configure the Event MIB tables to monitor the ifTable for network interfaces being taken up or down, and triggering a linkUp or linkDown notification as appropriate.