Re: test

[Martin Pala]

Jan-Henrik Haukeland wrote:

> Igor Homyakov <address@hidden> writes:
>
>  
>
> > is it possible to check connection(s) without 
> > checking process ?
> >    
>
> Not as monit is now. Since monit is very localhost centric I guess we
> (or at least I) simply haven't thought about this. 
>
> But it is very easy to change this so a connection test may become a
> standalone statement because all network code for doing this is
> already in place. The only thing to change is the control file grammar
> to allow such a standalone statement. From the top of my head, such a
> statement may look like this:
>
> check host rhn.redhat.com:443 with type TCPSSL
>  if failed connection with timeout 15 seconds then {..}
>  if failed protocol http and request "/cgi-bin/login.cgi" then {..}
>  alert address@hidden
>
> But since we, right now, are in the process of releasing the monit 4.0
> code as a beta and in a week as a full release I'm not sure we have
> time to add this. But it is very tempting to do so :-)
>
> What do others think? Is it interesting to add an external standalone
> connection test to monit?
>
>  
I agree, it is very interesting.

I think the implementation should utilize present tests (aka object 
modules) without changing it. It is sufficient to add new monitoring 
service type reflecting present convention - i.e. each service has its 
token (shortcut), which is used by monit for example for dependencies, 
monitor/unmonitor commands, etc.

For example the syntax could be (basic):

(1) check host up2date-http with address 66.187.232.110
(2)   if failed host rhn.redhat.com port 80 protocol http and request 
"/my/index.html" then alert
(3)   if failed host rhn.redhat.com port 443 type tcpssl protocol http 
and request "/my/index.html" then alert

On line 1 'host' identifies host monitoring service class + defines 
'up2date' as this service instance token and server's address (it is 
better to use IP address to bypass potential name resolving problems). 
The second line is exactly the same test, which is supported in 
'process' monitoring service - it is important to support hostname 
option too because of virtual host. Line 3 defines another service which 
is part of this instance.

More complex example:

(1) check host up2date-http with address 66.187.232.110
(2)   if failed host rhn.redhat.com port 80 protocol http and request 
"/my/index.html" then alert
(3)   if failed host rhn.redhat.com port 443 type tcpssl protocol http 
and request "/my/index.html" then alert
(4)
(5) check host up2date-ftp with address 66.187.232.110
(6)   if failed port 21 protocol ftp then alert

This example shows just the fact, that it is possible to define more 
monitoring service instance for the same server. This is usefull for 
example if you need to take care for different services running on the 
same host different way. For example you can define dependency fir 
service running on localhost to depend on specific host monitoring 
service instance. You can monitor other service running on the same 
remote host in other host monitoring service instance and take care for 
another dependency chain (or use it as standalone service as usual). The 
advantage is, that the host monitoring service instance could agregate 
more ports if needed (if it makes sense).

The implementation of such check will be very easy, because monit has 
framework for it now.