On Wed, Jun 22, 2011 at 4:54 AM, Giuseppe Modugno <[email protected]>wrote:
> ** > On 22 Jun 2011 at 9:10, Dave Shield wrote: > > On 22 June 2011 08:50, Giuseppe Modugno <[email protected]> > wrote: > ... snip ... > > > I'm wondering what is the best approach between creating 10 > different > > > notifications with own OID (oidNotifV1Alarm, oidNotifV2Alarm, ...) > or > > > creating just one notification (oidNotifVAlarm). > > > > One notification with an explanatory payload would be better. > > Yes - this is a perfectly valid (and common) approach - see the > > other notification definitions for similar examples. > > I tried to look at notifications defined in standard MIBs, but I > couldn't understand how to solve my particular case. > > I have the following objects defined in myMIB: > > myV1 OBJECT-TYPE > SYNTAX Integer32 > UNITS "V" > MAX-ACCESS read-only > STATUS current > DESCRIPTION "First voltage" > ::= { myMIB 1 } > > myV2 OBJECT-TYPE > SYNTAX Integer32 > UNITS "V" > MAX-ACCESS read-only > STATUS current > DESCRIPTION "Second voltage" > ::= { myMIB 2 } > > ...and so on. > > How should I define one notification that includes the correct > informations about the object that triggered the alarm and its value? What > should I write in OBJECTS field? > > myVoltageAlarm NOTIFICATION-TYPE > OBJECTS { ??? } > STATUS current > DESCRIPTION > "Notification that the rising threshold was met for triggers > with mteTriggerType 'threshold'." > ::= { myNotifications 1 } > > Thank you for your support. > As Dave suggested... use a table. I have done that exact thing in some of our products. (I have tables for voltages, temp sensors, fan spped/control, etc) I won't provide a compilable MIB (actually I attached an extract from my MIB), but the general structure is: voltageTable OBJECT-TYPE SYNTAX SEQUENCE OF voltages voltageEntry OBJECT-TYPE SYNTAX VoltageEntry VoltageEntry ::= SEQUENCE OF { nominalLevel INTEGER, currentLevel INTEGER lowerThreshold INTEGER upperThreshold INTEGER } nominalLevel OBJECT-TYPE -- in 0.1 volt units ... currentLevel OBJECT-TYPE ... lowerThreshold OBJECT-TYPE ... upperThreshold OBJECT-TYPE ... voltageAlarm NOTIFICATION-TYPE OBJECTS { nominalLevel, currentLevel, lowerThreshold, upperThreshold} ... a) the sender provides the thresholding and the thresholding hysteresis (to reduce flapping alarms). b) the receiver can now determine which supply failed and by comparing the current level (provided) with the thresholds (provided) can determine whether the trap is signifying going 'into alarm', versus going 'out of alarm' (aka 'back to normal') all with a single trap definition. Note that you could return only the currentLevel in the trap, and use the indexing information on the OID for that currentLevel to then go back and read the values of the other variables associated with that supply, BUT I've found it much better/simpler to have the agent provide all the related information in the trap (primarily because... by the time an NMS gets around to processing the trap, and querying for any 'related' data, that data may have changed and can't be relied on to provide the accurate information that triggered the trap in the first place. Oh... and why do all this inside the app rather than use DISMAN? Because that system was an embedded system that wasn't based around Net-SNMP, so DISMAN wasn't (readily) available. Fulko
sample_power.mib
Description: Binary data
------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
