Re: contignuous alert supression

[Martin Pala]

Igor Grabin wrote:
> On Mon, Jan 31, 2005 at 11:36:52PM +0100, Jan-Henrik Haukeland wrote:
>
> > > check host somehost with address [some address here]
> > > if failed port 80 proto http then alert
> > >
> > > there is a network lag, so I sometimes get false alerts.
> >
> > Monit has a default 5 second timeout and you should increase the 
> > timeout to avoid alerts on network lag. Use for example
> > check host somehost with address [some address here]
> > if failed port 80 proto http with timeout 15 seconds then alert
>
> I use 20. that doesn't save me from initial syn being dropped due to
> the overloaded outbound link. users don't care, higher-ups too.
>
>
> > That way every alert mail from monit can be taken seriously, as it 
> > should :-)
>
> I'm completely sure about my initial question, as I've read the
> manual, and have already tried what could be done. See above.
>
> I'm completely sure that I want monit to allow to be configured to
> send contignuous alarms.
> Current way its alerts only read 'outbound bandwidth exhausted' for
> me, as the initial syn couldn't make it through. I don't need monit to
> be aware of that.

I agree with Hauk.

Current monit behavior is sufficient, because Monit has both error and 
recovery alerts. This means that you should take the alert seriously - 
until you will receive 'recovery' alert, you can be sure that the 
service is broken.

Your thesis is based on the fact, that when the service is failed for 
more then specific time limit, you know that the problem is not 
temporary (not related to 'outbound bandwidth exhausted').

I see no problem in this sense with current monit behavior - it will 
send you alert and when you will not receive recovery alert in specific 
timeframe (which you know), the problem is persistent according to your 
rules.

The only diferrence that i can see is, that the feature you requested 
floods your mailbox, mobile phone or whatever by alerts and this way 
forces you to solve the problem: either repair the service or destroy 
the mobile ...