[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Feature request and reverse condition
From: |
Martin Pala |
Subject: |
Re: Feature request and reverse condition |
Date: |
Thu, 8 Sep 2011 00:38:21 +0200 |
On Sep 7, 2011, at 8:09 PM, cgzones wrote:
> Hi list,
> I want to act on a specific event very soon, and be sure that the event was
> not only an exception.
> So the only option i found is per "for X cycles", but a cycle can be very
> long.
> My thought is a directive like "with recheck [in X seconds]".
> An example (for ssh-service):
> if failed host localhost port 22 protocol ssh then restart -> if failed host
> localhost port 22 protocol ssh with recheck in 3 seconds then restart
>
> If then condition fails one time, he check the comparison in 3 seconds again,
> and if it fails again the action is done (restart), else only an alert is
> send or nothing is done.
> So with these method i/monit can react quicker than with "if failed host
> localhost port 22 protocol ssh for 2 cycles then restart", because a cycle
> takes 20-120 seconds;
> and more secure than "if failed host localhost port 22 protocol ssh then
> restart", because the check failed two times.
Hi,
the next monit version (5.3) provides similar feature - it supports the
connection "retry" option which allows to do multiple tries in the same cycle
to make sure the error is hard and doesn't recover with retry.
> Another question:
> I want to check my firewall; it should block for example all
> mysql/smtp-requests from outside.
> So with the following lines, monit alert when a connection fails; but i want
> to get an alert when the connection does not fail.
> if failed host localhost port 25 protocol smtp then alert
> if failed host localhost port 3306 protocol mysql then alert
>
> Is there an alias-action, like "if failed host localhost port 25 protocol
> smtp then donothing else if succeeded then alert" or what else can i do?
The current connection test is failure=error oriented, but the support for
success=error makes sense in the scenario which you described. We may add such
feature in the future.
Possible workaround: the next Monit release (5.3) will support custom script
based checks, so you can use for example netcat to check that the connection
fails using something like this:
--8<--
check program firewall_mysql with path "/usr/bin/netcat -z 1.2.3.4 3306"
if status == 0 then alert
--8<--
The netcat returns 1 if the connection failed and 0 if it succeeded => the
alert will be send only if connection to 1.2.3.4:3306/tcp succeeded.
Regards,
Martin