Re: plans

[Jan-Henrik Haukeland]

Interesting suggestion. It would require a major update of the parser
and the backend processing logic. This doesn't mean it will be overly
complicated as Christian also mentioned later in the thread, but it
will require some work. 

I also like this clean suggestion, Martin, and the current language
does start to get messy. Christian is also right about that a global
method section would be useful, because most of the methods (except
start/stop) may be reused by many different check-blocks.  Maybe the
cleanest is to only leave the start/stop commands in a check-block and
define other methods globally?  As in

# Global method definition section
  method reload "kill -HUP $MONIT_PROGRAM_PID"
  method shutdown "/sbin/shutdown -t 1 bye, bye"
  method foo "/bin/xzz -option 1 ... -option N  argument1.. argumentN"
  method bar "/bin/xyz -option 1 ... -option N  argument1.. argumentN" exec on {


# check section
check ...
 start program = "/usr/local/apache/bin/http start" 
 stop program  = "/usr/local/apache/bin/http stop"
 # tests definition section
  if timestamp /usr/local/apache/conf/httpd.conf was changed then exec reload
  if cpu usage > 80% then exec foo
  if cpu usage > 99% then exec shutdown

But what should be do with these statements? 

  checksum /usr/local/apache/bin/http 
  timeout if 2 restarts within 3 cycles
  group server
  every 2 cycles
  depends sybase
  alert address@hidden on { checksum }
  host shop.sol.no port 443 type TCPSSL protocol http

They are not if-tests per se. Should we leave them as is or modernize
them as well?


Martin Pala <address@hidden> writes:

> I think maybe we can save some configuration file size and make it
> more clear, if we'll use syntaz as following:
>
> check ...
>   # method definition section
>   method start "/etc/init.d/apache start" exec on { start }
>   method stop "/etc/init.d/apache start" exec on { stop }
>   method reload "kill -HUP $MONIT_PROGRAM_PID"
>   method shutdown "/sbin/shutdown -t 1 bye, bye"
>   method foo "/bin/xzz -option 1 ... -option N  argument1.. argumentN"
>   method bar "/bin/xyz -option 1 ... -option N  argument1.. argumentN" exec 
> on {
>    timeout, restart, checksum, resource }
>   # tests definition section
>   if timestamp /usr/local/apache/conf/httpd.conf was changed then exec reload
>   if cpu usage > 80% then exec foo
>   if cpu usage > 99% then exec shutdown
>
>
> It separates method definition and allows to use different methods
> for different condition "levels" of events (see last two lines of
> above example). You can then make different actions for the same
> event appropriate to situation.
>
> It could be usefull for example in device checks - if the space
> usage is growing and is above for example 80% watermark, you can
> call method to purge some temporary or not important files (cores,
> etc.) or to compress/move them (it can be done on regular basis by
> cron, but monit could be used as fast reaction system for unusual
> situations such, where the filesystem is fullfiled and cron job is
> planned to midnigth). However if first method didn't helped, space
> usage grows and stop method could be called in the case that it
> exceedes 99% to gracefully stop services and defend catastrophal
> situation. This is just example for device checks - another cases
> are usefull for other monit tests (timestamp, etc.)
>
> I didn't though about implementation, so it probably could be lot of
> work (redesigning present start/stop program system). I thing it
> isn't needed in such case to change present alert statement (exec
> could be standalone list).
>
> What about it?
>
> Cheers,
> Martin

-- 
Jan-Henrik Haukeland