Re: monitoring snmp traps

2009-04-02 Thread Jim Trocki
On Tue, 31 Mar 2009, Mike Ireton wrote:

> running on the same host. The snmp traps received by snmptrapd get
> written to syslog where I have a process (syslog-ng / swatch) running to
> do primitive decoding of the messages and sending alerts under some

>   I am no snmp guru but it seems that it should be possible and
> desireable for there to be many snmp trap receivers on the same host,
> each handling one or more subsets of the mib tree.

>   My question simply is how might anyone suggest to handle multiple traps
> from different devices or is there something obvious in the net-snmp
> package that I've missed or perhaps a mon feature I could use for this
> purpose?

snmptrapd can be told to decode traps matching particular OIDs and send
them to an external program's stdin, or it can forward traps matching
some OIDs to another destination, on the same machine or elsewhere.
check out the man page for snmptrapd.conf, the "traphandle" and "forward"
settings.

you may be able to run a separate snmptrapd on the same host but listening on
a different port with a different configuration which uses "traphandle" to
call your mon-related trap processor, and the main snmptrapd would use the
"forward" config to send the work to the appropriate handler. this
would free up the main snmptrapd to handle other logging and forwarding
while allowing you to use multiple processes to handle the specific work.

___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon


Re: unidentified output from fping

2009-04-02 Thread Jim Trocki
On Wed, 1 Apr 2009, Alain wrote:

> I looked at fping.monitor from the latest distribution (mon-1.2.0) and
> see there's been a number of changes since the version I was using
> (0.99.2-13). Sure enough using this latest version of fping.monitor
> resolved them problem. However, I'm still curious what exactly the old
> fping.monitor saw that the new one doesn't? Any ideas?

the adjustment was to handle some extra icmp messages from routers which
indicate that a host was unreachable, rather than relying on just the timeout.

___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon