On 22 Jun 2011 at 8:50, Fulko Hew wrote:
> 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:
Indeed I have other signals too: temperature, currents, RF powers
and so on. Do you suggest to have a different table for each signal?
For example, I have only one temperature sensor: should I create a
table with just one row?
At first, it seems to me the "fixed one-row table" approach is too
complex compared with a single scalar/object approach.
> 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.
I don't know the details about the SNMP table, but how the receiver
can determine which voltage supply has broken? I think it receives
only four numbers: nominal, current, maximum and minimum levels. But
what happens to the index/row of the table?
> 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.
I understand your point, I think it's very good.
>From your words, I imagine there is an index/row that is transmitted
with the notification.
------------------------------------------------------------------------------
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
