Re: test

[Martin Pala]

Jan-Henrik Haukeland wrote:

> Martin Pala <address@hidden> writes:
>
>  
>
> > Jan-Henrik Haukeland wrote:
> > *
> >    
> >
> > > What do others think? Is it interesting to add an external standalone
> > > connection test to monit?
> > >
> > >      
> > I agree, it is very interesting.
> >    
>
> Let's add it then :-) Because by doing this simple thing (for us) it
> opens up a whole new ballpark for monit.
Yes :) I think it could be good to add it in 4.1, which could be 
released soon after 4.0 (this is non critical feature)

> Before we start we must agree on the syntax for the new statement
> though. Your proposal:
>
>  check host up2date-http with address 66.187.232.110
>    if failed host rhn.redhat.com port 80 protocol http then {...}
>    if failed host rhn.redhat.com port 443 type tcpssl protocol http
>      and request "/my/index.html" then {..}
>    alert address@hidden
>
> Is good because it lets us keep the current if-connection-test as it
> is and can use several connection tests in an entry. But the syntax is
> a bit redundant, since the hostname/address is given twice. It is easy
> to write a new rule in the parser for a remote connection test, so we
> do not *need* to keep the connection test as it is for a remote test.
>
> Here is another suggestion, modeled after your check-file test, where
> the host and port is given in the check line and the if-test simply
> refere to the host and port:
>
> check host rhn.redhat.com port 80
>   if failed protocol http and request
>      "/my/index.html" and with timeout 15 seconds then {...}
>   alert address@hidden
>
> The drawback with this solution is that since the host and port is
> stated in the check-line there can only be *one* if-failed.. test. So
> if you want to test more than one port at the server you must write
> several check-host statements.
>
> Finally, here is a suggestion using a rewrite of your proposal. Here
> the check-block simply contains a descriptive name for the connection
> test. [In the parser we will also require that host is stated for a
> remote connection test (in the current grammar host is not required
> and if not stated is assumed to be localhost).]
>
>  check connection redhat <- redhat is just a descriptive name for the test
>    if failed host rhn.redhat.com port 80 protocol http and request
>      "/my/index.html" then alert
>    if failed host rhn.redhat.com port 443 type tcpssl protocol http
>      and request "/my/index.html" then alert
>    alert address@hidden
This has small drawback too - for example it could be good to add 
optional icmp echo request test (some machines can deny icmp by default 
so it should be optional). In such case this syntax requires 
specification of the host in icmp test statement, such as:

check connection redhat
if failed host rhn.redhat.com port 80 protocol http and request 
"/my/index.html" then alert
if failed host rhn.redhat.com port 443 type tcpssl protocol http and request 
"/my/index.html" then alert
if failed icmp host 66.187.232.110 type echoRequest then alert
alert address@hidden




=> you must specify the host too - in the case that there will be 
another tests (icmp provides more interesting types then just 
echoRequest), the host specification will become more reduntant then in 
the first proposal (specification of the host for each test).

In addition 'host' portion of the test is optional - it is interesting 
to use it in the case of remote host monitoring only if you need to use 
virtual hosts. If it is not your case, the first proposal could be 
simply written as:

check host up2date-http with address 66.187.232.110
if failed port 80 protocol http then {...}
if failed port 443 type tcpssl protocol http and request "/my/index.html" then 
{..}
if failed icmp type echoRequest then alert
alert address@hidden


Btw. the icmp test syntax is interesting as well - some options (the 
utilization of host specification depends on particular above syntax 
proposals):

1.) if failed ping [host 66.187.232.110] then alert

or

2.) if failed [host 66.187.232.110] type icmp protocol echoRequest then alert

or

3.) if failed icmp type echoRequest then alert


The first is nost simple, but in the case that more ICMP types will be 
implemented, it will require new standalone tests (for similar thing) => 
i think it is not suitable.

The second is nice, but we can't probably base it on extended port test 
(because it doesn't need port specification) => it could be problematic 
(just first sigth - maybe it will be simple and possible). The usage of 
'type' is not accurate too (mixture of different network layers - IP 
based protocols vs. ICMP word is not correct).

The third is maybe the cleanest of all - the usage of 'type' word is 
correct in the context of port test.

Conclusion:

I preffer first proposal and the third form of icmp echo test:

check host up2date-http with address 66.187.232.110
if failed port 80 protocol http then {...}
if failed port 443 type tcpssl protocol http and request "/my/index.html" then 
{..}
if failed icmp type echoRequest then alert
alert address@hidden


Martin