[Top][All Lists]

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

Re: contignuous alert supression

From: Martin Pala
Subject: Re: contignuous alert supression
Date: Wed, 02 Feb 2005 19:05:50 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1

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 ...

reply via email to

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