check host syntax

[Martin Pala]

Hi,

I think present syntax has drawback in port test and virtual hosts area. 
Taken from monit.pod:

--SNIP--
E.g. this is legal:

check HOST ftp.redhat.com
  if failed port 21 then exec
   "/usr/X11R6/bin/xmessage -display :0 RedHat is down as usual!"

this is not, and will lead to a parse error:

check host ftp.redhat.com
  if failed HOST ftp.suse.com port 21 then ...
--SNIP--

This means that:
- you must define one check host statement for each virtual host running 
on the same node, which is more expensive then have it in one host statement
- it breaks general port test syntax - it behaves different way for 
remote hosts tests (doesn't support host definition) and for local 
processes tests (supports host definition)



In addition i think it could be usefull to support remote host tags as 
in process, device, file and directory tests. In the case that these 
"service names" will not be supported, it will break the convence of 
other checks. For example in the case of file check, it could be 
possible to write:

1.)  check file /bin/su

instead of:

2.)  check file su with path /bin/su

The first syntax (new 'check host ...' pattern) seems nice, but in the 
case of long paths (which is not su's case) it is better to use shortcut 
like 'su' then the complete path. Hosts are the same case - in the case 
that you have very long hostname IPv4 or finaly IPv6 address, it will be 
better to use shortcut for service manipulation then host definition. 
Similarily we use tag for process checks instead of pidfile path. It 
affects command line, as well as webinterface. Example syntax 
(consistent with present service tags syntax):

check host redhat with address 66.187.232.110


=> conslusion:

- what about to support host option in port test for remote hosts?
- what about to support service tags/names for remote hosts?


I know we discussed it recently on the list and i will not to remain on 
my proposal, but about notes seems rationaly problematic for me. If you 
want to, we can keep present implementation as it is - just my 0.02$ :)

Martin