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):
http://savannah.nongnu.org/cvs/?group=monit
- 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()
Martin
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:
>> http://lists.nongnu.org/mailman/listinfo/monit-general
>>
>
>
--
To unsubscribe:
http://lists.nongnu.org/mailman/listinfo/monit-general