Erno,
Erno Rigo wrote:
>
> 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?
>
That you only call the receivers that can handle that specific trap type
(matched by OID)
> 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.
>
The idea is this:
ID | POS | OID | COMMAND
1 | 99 | .* | unknown_trap
2 | 1 | .1.2.2.3.3 | specific_trap_handler
This way if we get a trap for the specific OID we call the 'specific trap
handler' script, but if the OID is not in the table, then we call the 'unknown
trap' handler that will print the trap varbinds in an event (an unknown type
event).
> 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.
Events have 4 fields: user, interface, info, state. Those are the variables you
can use in the event types. Like <interface> when you want the events screen to
show it.
>
> 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?
You don't know which trap you may encounter.
The trap receiver should return an array that should be passed to the backend.
(I don't like the idea of using the same backends as the pollers)
The default 'event' backend will use the interface, state, user, date, host and
info fields to create an event entry.
Other backends could use other fields.
>
> 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).
>
It is, but that's specific to the polling system, and I would not like to repeat
that here.
> 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?
Currently no, I know the poller->backend communication (strings piped or not) is
not good, but it has been working fine for polling because a poller should
return only a few values, maybe one value for a different backend (using the
multiple temporal buffer).
>
>>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 think we should have another backend system for traps. Maybe not a table, but
I would not like to share the backends/ folder with traps.
Since the polling system and the trap system will use different calling methods
for the backed (arrays instead of strings), we should have them in a different
folder.
If you need shared functionality you can have you code in the shared/ folder and
call it with the jffnms_shared () function.
> 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?
>
In the future we could have a receiver->backend system for syslog events. That
will make it more flexible, like allow for a different action than "insert a new
event".
But again, I don't want to mix the poller backends with other backends.
Maybe the trap backends and the syslog backends could be the same, but the
poller ones are too specific.
Thanks again for taking care of this. And I hope seeing your new patch soon.
Javier
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Javier Szyszlican, Project Leader, JFFNMS
[EMAIL PROTECTED]
I hope JFFNMS or I were helpful to you, if you
can, please donate at http://jffnms.org/donate
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
jffnms-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jffnms-users
