[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sending alerts only on failure, not on recovery

From: Martin Pala
Subject: Re: Sending alerts only on failure, not on recovery
Date: Thu, 14 Dec 2006 23:11:17 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061105 Iceape/1.0.6 (Debian-1.0.6-1)

Thanks :)

Regarding the second feature request, it is planned (

You can also use the existing generic send/expect protocol test, which is built-in - example:

 if failed host port 4040
    send "Open, Sesame!\r\n"
    expect "Please enter the cave\r\n"
    send "Shut, Sesame!\r\n"
    expect "See you later [A-Za-z ]+\r\n"
 then restart


Chris Metcalf wrote:
Ok I'll take a look :)

The other functionality I'd like is the ability to run arbitrary
scripts and alert based on their output. I'd like to script things
like unit tests of webpages and response times of various services. I
think it would make monit a lot more flexible.

- Chris

On 12/14/06, Martin Pala <address@hidden> wrote:
Yes, patches are very welcomed :)

The question is the syntax and the functionality scope.

The recovery/failure filter should be optional per each 'alert'
statement - some users of the same monit instance may want to receive
recovery alerts, whereas some other don't.

There may be also users which may want for example receive just the
recovery alert. The alert statement is already quite verbose, since it
allows to filter the particular event types (even negated list which is
new in 4.9-cvs) and set the mail format.

Maybe following syntax may be used (just my 0.02$):

   alert <address> [not] [failed|recovered] ['{' <type>,... '}']

Some examples ('just', 'on', 'but' are just noise words):

  alert address@hidden
    ... all alerts

  alert address@hidden just on failed
    ... all failed alerts

  alert address@hidden just on recovered
    ... all recovered alerts

  alert address@hidden on { exec, timeout }
    ... just exec and timeout alerts, both failed and recovered

  alert address@hidden on failed { exec, timeout }
    ... just exec and timeout alerts, failed only

  alert address@hidden on recovered { exec, timeout }
    ... just exec and timeout alerts, recovered only

  alert address@hidden but not on { exec }
    ... all alerts except 'exec', both failed and recovered

  alert address@hidden but not on failed { exec }
    ... all alerts except failed 'exec'

  alert address@hidden but not on recovered { exec }
    ... all alerts except recovered 'exec'

The implementation itself should be quite easy - few hints for start:

- use the cvs version (new code was added since 4.8.2):

- the lexer  l.l keeps the keywords (most probably no change needed)

- the parser p.y parses the configuration file (see 'setalert' and 'alert')

- the optional per-recipient recovery alert filter should be handled in
alert.c, handle_alert()


Chris Metcalf wrote:
> Do you welcome patches? I might take a look at making the change myself.
> - Chris
> On 12/13/06, Martin Pala <address@hidden> wrote:
>> Hi,
>> monit doesn't allow to turn off the recovery event currently. It should >> provide the feedback that the service is up again so the admin can sleep
>> in peace again ;) Maybe we can make the recovery alarm optional in the
>> future monit versions.
>> You can also use some workarounds, such as set the mail server or
>> client-side filter to remove the recovery message.
>> Martin
>> Chris Metcalf wrote:
>> > I _love_ monit. Its been very handy and its saved my butt more than a
>> > few times.
>> >
>> > Recently I set it up to email my blackberry with a specially formatted
>> > message for critical failures, so that it "pages" me and I can
>> > manually verify that everything is OK. Its great, except for the fact
>> > that I end up actually getting two alerts - one when the problem
>> > occurs and one when its cleared. Thats kind of annoying.
>> >
>> > Is there any way to set up a particular alert to only be sent on the
>> > failure state and not the recovery state?
>> >
>> > I'm running monit 4.8.1 on Debian.
>> >
>> > Thanks,
>> --
>> To unsubscribe:

To unsubscribe:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]