Hi Dave:
First,Sooooooooooooorry.
I found the manual below.But I can hardly got you "use the DisMan Event MIB"
exactly meaning,How do I implement this? Write the config info into the
snmptrapd.conf file?
Just like:
monitor -o prNames -o prErrMessage "process table" prErrorFlag != 0
and I do this:
monitor -o uitUPSNames -o uitUPSErrMessage " UPS failed! " uitUPSErrorStatus !=
1
Whether one trap object can send the different information? Such as,one value
get from the sensor higher or lower than the set value,then the trap can notify
the difference(that is to say one trap identifier,but send different
information.).
Alex
DisMan Event MIB
The previous directives 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.
This requires that the agent was built with support for the disman/event module
(which is now included as part of the default build configuration for the most
recent distribution).
Note:
The behaviour of the latest implementation differs in some minor respects from
the previous code - nothing too significant, but existing scripts may possibly
need some minor adjustments.
iquerySecName NAME
agentSecName NAME
specifies the default SNMPv3 username, to be used when making internal queries
to retrieve any necessary information (either for evaluating the monitored
expression, or building a notification payload).
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).
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 delected. An expression of the form !=OID specifies a
changed(2) test, which will fire whenever the monitored value(s) change.
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.
OID MIN MAX [DMIN DMAX]
defines a threshold(1) 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) or rises 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 re-armed 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 behaviour 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
option is not given, the monitor entry will generate one of the standard
notifications defined in the DISMAN-EVENT-MIB.
-I
indicates that the monitored expression should be applied to the specified OID
as a single instance. By default, the OID will be treated as a wildcarded
object, and the monitor expanded to cover all matching instances.
-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
first starts up. The first evaluation will be done once the first repeat
interval has expired.
-s
indicates that the monitor expression should be evaluated when the agent first
starts up. This is the default behaviour.
Note:
Notifications triggered by this initial evaluation will be sent before the
coldStart trap.
-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 [-n] [-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 -n 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 behaviour of the Net-SNMP Event MIB implementation.
Unfortunately, the DisMan Event MIB specifications actually state that the
trigger-related varbinds should come first, followed by the event-related ones.
This directive can be used to restore this strictly-correct (but inappropriate)
behaviour.
Note:
Strict DisMan ordering may result in generating invalid notifications payload
lists if the notificationEvent -n flag is used together with monitor -o (or -i)
varbind options.
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.
This is exactly equivalent to the configuration:
notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus
notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus
monitor -r 60 -e linkUpTrap "Generate linkUp" ifOperStatus != 2
monitor -r 60 -e linkDownTrap "Generate linkDown" ifOperStatus == 2
defaultMonitors yes
will configure the Event MIB tables to monitor the various UCD-SNMP-MIB tables
for problems (as indicated by the appropriate xxErrFlag column objects).
This is exactly equivalent to the configuration:
monitor
-o prNames -o prErrMessage "process table" prErrorFlag != 0
monitor
-o memErrorName -o memSwapErrorMsg "memory" memSwapError != 0
monitor
-o extNames -o extOutput "extTable" extResult != 0
monitor
-o dskPath -o dskErrorMsg "dskTable" dskErrorFlag != 0
monitor
-o laNames -o laErrMessage "laTable" laErrorFlag != 0
monitor
-o fileName -o fileErrorMsg "fileTable" fileErrorFlag != 0
In both these latter cases, the snmpd.conf must also contain a iquerySecName
directive, together with a corresponding createUser entry and suitable access
control configuration.
------------------ Original ------------------
From: "Dave Shield"<d.t.shi...@liverpool.ac.uk>;
Date: Mon, Feb 8, 2010 10:02 PM
To: "Alexander King"<chenyapu1...@qq.com>;
Cc: "net-snmp-users"<net-snmp-users@lists.sourceforge.net>;
Subject: Re: How to send the traps in different way.
On 8 February 2010 12:28, Alexander King <chenyapu1...@qq.com> wrote:
> The initializing had done.I use function snmp_alarm_register() send the
> trps each time at a predetermined time period(10 seconds, or 30 seconds).
>
> But,I want to send traps like this:
> 3.just send it;
Call the routine sendXxxTrap()
(as generated by mib2c.notify.conf)
> 1.when the value changed;
> 2.when the value is higher or lower than a specific value;
The easiest way to do these two would be to use the
DisMan Event MIB. See the snmpd.conf(5) man page
discussion of the "monitor" directive.
Or else insert a call to sendXxxTrap into the code that
loads the contents of the table.
Dave
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
