Re: timestamp monitoring + code simplification patch

[Martin Pala]

Jan-Henrik Haukeland wrote:

> Christian Hopp <address@hidden> writes:
>
>  
>
> > The syntax is right now,
> >
> > CHECK name PIDFILE path ...options... (1)
> >
> > If we want to be "compatible" with (1) we need the following,
> >
> > CHECK name [PIDFILE|DEVICE|DIRECTORY|FILE] path ...options...
> >    
>
> But do we want to be quite that compatible? since it makes for some
> awkward statement like.
>
>  
>
> > CHECK iplanet_stored FILE "/usr/iplanet/msg-ims1/config/stored.ckp"
> > CHECK foo_dir DIRECTORY "/foo/directory"
> > CHECK mylittlebigharddisk DEVICE /dev/hda1
> >    
>
> IMO it looks better, simply to say:
>
> CHECK FILE "/usr/iplanet/msg-ims1/config/stored.ckp"
> CHECK DIRECTORY "/foo/directory"
> CHECK DEVICE /dev/hda1
>
> [FILE, DIRECTORY and DEVICE will become reserved keywords.]
>
> that way you are spared for making up imaginary descriptive names for
> the file, directory and device like 'iplanet_stored'.
>
> It will not crash with the current check statement either (1):
>
> CHECK name PIDFILE PATH
>
> To summarize, I vote +1 for using the following check statements:
>
> CHECK name PIDFILE PATH
> CHECK [FILE|DIRECTORY|DEVICE] PATH
>
> In addition maybe include this variant for the process check statement
> for symetrical reasons:
>
> CHECK PROCESS name PIDFILE PATH
>
> What do you think?
>
>  
I agree, so we can have:

CHECK [FILE|DIRECTORY|DEVICE] PATH options,...
CHECK [PROCESS] name options,...


Next possibility can be to make name standalone option such as "NAME 
name". It could be required (for PROCESS only) or optional statement 
(for all major statement types). If it will be defined for PROCESS as 
optional too and the "NAME name" won't be defined, monit can take its 
name from common required option (path) or map the process's pid to its 
name from process table. PIDFILE will come in such case empty helper 
word. Syntax:

CHECK [PROCESS|FILE|DIRECTORY|DEVICE] PATH options,...


1.) example (verbose version):

CHECK PROCESS [WITH PIDFILE] "/var/run/sshd.pid"
 NAME sshd
 START "/etc/init.d/sshd start"
 [...]

CHECK FILE "/data/customer"
 NAME journal ( ... FILE type needn't support for this statement - it 
can be completely avoided in the parser)
 SIZE > 10 MB ALERT
 TIMESTAMP > 1 DAY ALERT
 [...]

2.) example (less verbose version):

CHECK PROCESS "/var/run/sshd.pid"
 [NAME sshd] ( ... it could be >optional< there as well OR it can be 
PROCESS type >required< option)
 START "/etc/init.d/sshd start"
 [...]

CHECK FILE "/data/customer"
 SIZE > 10 MB ALERT
 TIMESTAMP > 1 DAY ALERT
 [...]


I'm inclined maybe more for this syntax and to make "NAME name" optional 
for PROCESS too. In the case that the user won't define "NAME name", we 
can use just required path to the pidfile as process/object's name - the 
user should know what he does, when he don't use NAME statement, so as 
described above, extra mapping the process PID to the name won't be 
needed. Optional NAME statement for other types can be usefull to have 
shortcut for the event of error message (it could be used to avoid 
receiving path to the file/device/etc. on the mobile phone).

What about it? If it won't be acceptable for you, i agree with Jan's 
syntax (not to require name for other major statements such as FILE, etc.)

Martin