Re: snmp_trap_receivers and snmp_table patches ... and a question
Javier Szyszlican <
javier@...>
2005-04-01 14:14:08 GMT
Hi Erno,
I'm glad you like JFFNMS so much. :)
And thank you very much for contributing this code.
I'm glad someone finally tried to fix the SNMP Trap system.
This seems like a perfect start.
I did a quick look and your code seems clean and usable.
Automatic ACK:
There's no GUI to disable it. But it should only a checkbox and a if in the
events consolidator.
SNMP_TABLE:
I've no problem in including the snmp_table discovery system once you provide an
interface type that uses it.
Also, please download a current -devel, I've included a system (integrated to
snmp_walk) that can reduce the OID (if you wanted to include the oid) to 1 or 2
"." dots. So, you don't need to do the explode(".") and count() stuff to reduce
that, it will simplify the snmp_table file. Look at the cisco PIX discovery
script for an example.
SNMP_TRAP system:
I don't like the idea of receivers->backend like in polling. The receivers idea
is great, the backend part is what I don't like.
My idea is something like this:
- We get a trap with OID X.
- Call all receivers that match a regexp for that OID (but break on the first
match),
and pass them all the varbinds and the OID. (Just like you do now)
We should have a last resort receiver that will match anything and generate
the unknown trap events. You should include a pos fields in the trap_receivers
table to make it only work if no other receivers exist.
- The receiver should return a few fields:
matched = bool = if the trap was understood.
interface = string = interface name
status = string = should be in the alarm_status table
user = string
info = string
You will see this fields are the ones in the events table.
- then the system will have only one backed, itself.
if the matched field is true, then a new event will be inserted using the
provided fields. I see no point in having more than 1 backend. Do you?
I also didn't like the "interface mask" stuff. The receivers should return the
full interface name that the events consolidator will later use to create the
alarms (if needed).
So, in my point of view, you are 80% there.
What do you think?
Javier
Erno Rigo wrote:
> Hello!
>
> First of all: Javier: let me congratulate to this fine product. I was quite
> desperate to find a GPLed NMS that allows us to trash HP's OpenView (!) ...
> now we are on the way to achieve our goal.
>
> In the meantime I had the 'oppurtunity' to change a few things in your latest
> release. Attached to my mail comes my patch against 8.0.1 with the following
> two changes:
>
> I.: I had to find a way to recognize different interfaces of our embended
> remote monitoring device. The interfaces are all stored in SNMP tables so i
> wrote a generic snmp_table discovery plugin. This is an excrept from the
> diff:
>
> + * Generic SNMP table discovery
> + *
> + * Parameters:
> + *
> + * OID,field,filter,basename
> + *
> + * Where:
> + * OID - snmp table base OID
> + * field - snmp table field to be present (appended to OID)
> + * filter - PHP evaluative expression to filter table indices
> based the field's value
> + * can be used to detect 'active' interfaces only
> + * basename - base interface name for discovered and filtered
> table entries
> + *
> + * Example:
> + *
> + * 1.3.6.1.4.1.2069.1.2.1.1.9.2,1.7,>0,Door Sensor
> + *
> + * This will detect Door Sensors from the table at
> 1.3.6.1.4.1.2069.1.2.1.1.9.2
> + * where eval("1.3.6.1.4.1.2069.1.2.1.1.9.2.1.7.n >0") returns true,
> + * the resulting interfaces will be called "Door Sensor [n]" where n is
> the SNMP table index.
>
> II.: I had a hard time using "SNMP Trap Rules". I took a look in your TODO
> list and came up with an idea: SNMP trap receiving is so similar to polling
> that i've seen it very useful to implement trap receiver frontends using the
> same backend mechanism you used in the polling configuration.
>
> So I implemented "SNMP Trap Receivers" plugins in this way, defined a plugin
> interface, modified the trap consolidator to launch the plugins, created a
> mysql db diff for the new receivers table, and implemented one basic receiver
> plugin called 'state_trap_receiver' witch maps traps to interface alarm
> states like the snmp_status poller plugin does. An excrept from the diff
> follows again:
>
> + * Receive state type SNMP traps - similar to the poller called snmp_status
> + *
> + * Parameters:
> + *
> + * interface_mask,state_variable,state_mappings
> + *
> + * Where:
> + * interface_mask - string mask used to determine interface name
> + * the name is then reverse-mapped to find the interface
> ID
> + * sould contain a substring like "%n%" where n is the
> + * snmp trap variable referring to the interface's number
> on that host
> + * state_variable - the snmp trap variable referring to the
> interface's state
> + * similar to poller snmp_status
> + * state_mappings - state variable alarm mappings in the format
> of
> + * value1=alarm1[|value2=alarm2[...]] where valueX is a
> value of
> + * state_variable and alarmY is a valid alarm state
> defined in
> + * the Alarm States configuration menu
> + *
> + * Example (see also discovery/snmp_table.php for a more complete picture):
> + *
> + * Door Sensor %1%,2,1=door closed|2=door recently closed|3=door open|
> 4=door recently open
> + *
> + * This would map snmp trap variable #1 to the interface name, so if
> variable #1's value
> + * is 2, the interface will be looked up as "Door Sensor 2". Then trap
> variable #2 will
> + * be mapped to an alarm state, for example if variable #2's value is 3
> the returned alarm
> + * will be 'door open'.
> + *
> + * This trap receiver plugin is designed to be used conjunction with the
> 'alarm' backend plugin.
>
> This second modification could be further extended to allow external events
> different from SNMP traps to be received and processed with the same
> mechanism. I hope some people will find my patch useful. I'm sure I do... 8)
>
> And at last but not least: my question.
>
> I understand that 'down' events on an interface generate an UnAcked entry in
> the event log and 'up' events on the same interface not only generate another
> event entry, but also Acks both the previous 'down' event and the freshly
> created 'up' counterpart also... is there an easy (I mean: GUI) way to
> disable this feature for some interfaces? I need my users to manually ACK
> e.g. doorsensor events.
>
--
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Javier Szyszlican, Project Leader, JFFNMS
javier@...
I hope JFFNMS or I were helpful to you, if you
can, please donate at http://jffnms.org/donate
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
RSS Feed