On Wed, 24 Nov 2004, Michael Vogt wrote:
>
> Well. I thought of another way to escalate an ongoing problem (e.g. to
> a manager) even if it is acked. I could create a monstatus.monitor that
> checks overall mon status using the client interface and alerts if
> there is continued failure of (important) service(s). This also has
> the advantage of providing a high level view.
>
> Anyone doing anything like this?
>
> Any thoughts?
that's kinda nasty.
really, all you have to do is comment out the part in sub do_alert where
it decides to not continue with the alert if $sref->{"_ack"} is set.
#
# no alerts for ack'd failures, except for upalerts
#
if ($sref->{"_ack"} == 1 && !($flags & $FL_UPALERT))
{
syslog ("notice", "no alert for $group.$service" .
" because of ack'd failure");
return;
}
get rid of the "return;" and you'll get the behavior that you want.
maybe this would be better off as a per-period config setting. for example,
watch abc
service lmnop
monitor fping.monitor
interval 5m
period L1: wd {Sun-Sat}
alert mail.alert peeps
alertevery 8h
period L2: wd {Sun-Sat}
alert mail.alert ack-peeps
continue_after_ack
where the alerts in L2: will keep going even after the failure is ack'd, but
the ones in L1 will stop being sent after the ack.
_______________________________________________
mon mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/mon
