It looks like that fixed the problem.
A question on the redistribute option, though - I'm not sure I can
follow how the configuration works. For example, my current "remote
server" config is:
watch Store13-2
service DRBD_Status
interval 15s
monitor DRBDCheck.monitor -s you
description Is\ DRBD\ working\ there?
period wd {Mon-Sun}
alert trap.alert mainmonitor
upalert trap.alert mainmonitor
If I try various "redistribute" options, the mon.cgi script tells me
that config is invalid:
Config try #1:
period wd {Mon-Sun}
redistribute alert mainmonitor
alert trap.alert mainmonitor
upalert trap.alert mainmonitor
Config try #2:
period wd {Mon-Sun}
redistribute alert trap.alert mainmonitor
upalert trap.alert mainmonitor
Any thoughts?
Thanks!
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David Nolan
Sent: Thursday, July 13, 2006 7:06 AM
To: mon@linux.kernel.org
Subject: Re: Problem getting traps to work correctly
--On Wednesday, July 12, 2006 16:30:08 -0500 Tim Carr
<[EMAIL PROTECTED]>
wrote:
<snip>
Looks like you've found a logic bug. The code to set the group &
service
in handle_trap to default/default has an error which causes it to set
the
group but never the service. I just commited a fix for this to CVS.
<snip>
In this case you're not getting an alert because the status bit of the
trap
is set to 0, which is the OK status. It looks like the remote.alert in
CVS
was never updated when Mon starting using that field. trap.alert was
rewritten... Since these two alerts server the same purpose I'm going
to
remove remote.alert from CVS.
<snip>
BTW, you might want to use the 'redistribute' config parameter for your
traps, that will cause all status updates to propagate to your main mon
server. That way you can see when the last test occurred at all times.
>From the current Mon manpage (in CVS):
redistribute alert [arg...]
A service may have one redistribute option, which is a special form of
an
an alert definition. This alert will be called on every service status
update, even sequential success status updates. This can be used to
integrate Mon with another monitoring system, or to link together
multiple
Mon servers via an alert script that generates Mon traps.
-David
_______________________________________________
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon
_______________________________________________
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon
