On Friday 01 April 2005 16.14, Javier Szyszlican wrote: Hello!
> 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.
Done that. I'll include the new patch later.
> 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.
I thought about this process again.
What's the advantage of removing the "OID Match" and "Name" fields from the
new trap receivers table and putting those two things 'out' into the plugins?
Do you see a possibility where two plugins could use different methods to
match an OID? Why not implement this only once? I do not really see the
benefints of the priorized receiver stack you explained... I thought every
trap would only match one receiver.
On the other hand: I don't see the need of a receiver returning 'user' as it
is already must be passed to the trap consolidator as the "Name" field
mentioned above.
I find the name 'user' somewhat confusing, maybe I don't understand the exact
interaction between events, alarms and interface states very cleanly, but
maybe the 'user' (or 'name') field is not needed at all for insert_event(),
or in this case for the whole trap receiver subsystem. I also have the same
problems with the 'info' field. The events table either should contain
arbitrary number of variables/parameters or only the most crucial ones,
shouldn't it?
I also think that the call of the alarm backend is a bit chaotic. Now my
receiver plugins, which in fact are based on your snmp_status poller,
supposed to return the 'info' and 'status' fields separated by a pipe ('|')
character. Personally i think this is a dirty hack from you from somewhere in
the past 8).
I think we should sanitize this behaviour and clean up the backend plugin
calling interface a bit. There should be a lot of parameters with unique
functionalities or only one associative array parameter but not both with
different and mixed roles. Internally the code should not use pipe separated
strings as tuples, i admit that is good when one wants to give parameters to
plugins through the gui but can be confusing when internal functions use it.
Do you have near-future plans on this area?
In your last mail you wrote:
> So, there should be a backend called 'event' that inserts an event.
Yes.
> You should have a traps_backends table too then.
On the contrary: i think there should be only one backend table (and one
backend plugin collection) as this would allow reuse of the backends. I've
already used this feature in a real-world scene and I think it's a
semantically clean and somewhat more comfortable solution than having to
enter multiple backend definitions for the same thing.
I'd also change the syslog rules processing unit into the same
receiver-backend scheme if I were you, so there could be three uses for the
backends.
What do you think?
--
Ern� Rig� [McRee] - ICQ#63266198 - Tel#+36-20-5209965
--
Try to look unimportant in combat. The enemy may be low on ammo.
pgpzwgqq1MvO2.pgp
Description: PGP signature
