[RFD] monit control file language

[Jan-Henrik Haukeland]

Request for Discussion: 
Theme: monit control file language


The intentions of this mail is to start a small discussion about the
monit control file language. First a quick background, The monit
control file language was never a thoughtfully designed language from
the start like we expect a real computer language to be. Instead the
control file language has evolved over time and elements have been
added to the language from what seemed appropriate at the time to it's
present manifestation. Personally I think the evolution has been kind
and that the language we have today is not too bad.

 [Compared with a real computer language it's really not a proper
 language at all. It does not have variables, nor any control flow
 constructs and so on. On the other hand a control file language is
 also quite different from a computer language and is much, much
 simpler (from the language developers view point, that is :) because
 it's main objective is limited to provide directives that give a
 server its instructions.

 But monit's control file language is expressed in a proper context
 free grammar and it is parsed and checked for syntax and semantics.
 This is good because it means that if the need should arise we will
 be able to add more advanced elements to the language without too
 much work.]

Never the less, there are issues with the current monit control file
language and Christian Hopp has expressed some considerations which I
share with him:

 [..] we should be generally careful that we have a small number of
 "reserved words".  Users could get easily annoyed if they have to
 search a whole day of a service name with isn't already reserved by
 monit.  Maybe it is possible to have separate namespaces for all our
 symbols.

At the moment the current number of keywords has not reached a "pain
threshold" for me but I can easily see that it may in the future. I
think that we at least should think about this and maybe have tought
out a solution strategy. I do not have any clear answers now and hope
we can discuss this and maybe also discuss other aspects of the
control file language you may have issues with. 

Please, *everyone* is very welcome to take part in this discussion!!


Ps.  The reason I also want to bring this up now is that we are
currently working on a new monit release which contains additions to
the control file language. The additions is kept in the current CHECK
idiom, that is:

  CHECK process options

The new extension added to monit by Martin Pala is the ability to
check devices and files on the system and the CHECK statement is
extended to include the following:

CHECK {DEVICE|DIRECTORY|FILE|PROCESS} service_name PATH /depends/on/context

And here are some examples compiled by Martin: (Note, The PROCESS
keyword is optional to keep the backward compability)


check process slapd with pidfile /var/run/slapd.pid
 start program = "/etc/init.d/ldap start" as user root and group root
 stop program = "/etc/init.d/ldap stop"
 port 389 protocol ldap3
 if cpu usage > 80% for 5 cycles then restart
 alert address@hidden
 mode active
 depends on datafs

check device rootfs path /dev/hda6
 if space usage > 99 % then alert
 if inode usage > 500000 then alert
 alert address@hidden
 group database
 mode passive

check device datafs path /dev/hda1
 start program = "/bin/mount /dev/hda1 /data"
 stop program = "/bin/umount /dev/hda1"
 if space usage > 80 % then alert
 if space usage > 99 % then stop
 if inode usage > 80 % then alert
 if inode usage > 99 % then stop
 alert address@hidden
 group database

check file su path /bin/su
 checksum /bin/su
 permission 4755
 #uid  root #not implemented yet
 #gid  root #not implemented yet
 alert address@hidden

check file datafile path /data/testfile
 permission 0700
 #uid  root #not implemented yet
 #gid  root #not implemented yet
 #if size > 100 MB then alert #not implemented yet
 #if size > 150 MB then stop #not implemented yet
 alert address@hidden

check directory bin path /bin
 permission 0755
 #uid  root #not implemented yet
 #gid  root #not implemented yet
 alert address@hidden

-- 
Jan-Henrik Haukeland