Re: How to send the traps in different way.
"Alexander King" <[email protected]>
| Newsgroups | gmane.network.net-snmp.user |
|---|---|
| Message-ID | <[email protected]> |
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"<[email protected]>;
Date: Mon, Feb 8, 2010 10:02 PM
To: "Alexander King"<[email protected]>;
Cc: "net-snmp-users"<[email protected]>;
Subject: Re: How to send the traps in different way.
On 8 February 2010 12:28, Alexander King <[email protected]> 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
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users