Re: Request for a new "script" service type

[Martin Pala]

Hi,

we discussed similar functionality in the past i think. I'm not sure, 
but i think we decided to not support scripts in monit.

First of all:

1.) the example which you showed is possible to integrate with monit 
already using existing file timestamp test as mediator: your script can 
be run from cron in regular intervals (for example each 5 minutes) and 
in the case that everything is ok, it could touch some file (for example 
"/tmp/check_myservice.ok"). This will update its timestamp, which can 
monit test this way:

---
check file myservice with path /tmp/check_myservice.ok
  start program = "/etc/init.d/..."
  stop  program = "/etc/init.d/..."
  if timestamp > 15 minutes then restart
---

In the case that the test fails, timestamp will be older then the limit 
and monit will do the action.

This can test virtualy anything - my friend is monitoring solaris volume 
manager this way (submirrors state) and i used it for testing Java 
Enterprise System Messaging server's stored process (formerly Sun ONE, 
formerly iPlanet, formerly Netscape ... :)) - see for example 
http://www.tildeslash.com/monit/doc/examples.php#iplanetmsg


2.) I think it could be maybe useful to have some form of check scripts 
"API". For example to test (various) volume manager metadevices it is 
usualy needed to use command-line utilities, whcih can be encapsulated 
in such test script.

However, in such case i think that the script should have some 
properties needed to cleanly integrate it as testing 'method' in monit.

On method side it should be possible to after its call to:
- return the event type known by monit
- return the event verbose description

On monit side it should be possible to set at least timeout for method 
(there could be some default value, such as 5 seconds).

I'm not sure whether it is good to define new 'script' object. I think 
it could be sufficient to support the generic testing method interface 
in all existing objects (i.e. 'process', 'device', 'host', 'file', 
'directory'). Example syntax:

---
check process myproc with pidfile /var/run/myproc.pid
  start program = "/etc/init.d/..."
  stop  program = "/etc/init.d/..."
  if failed script "/usr/local/bin/check-myservice" then alert

check device rootfs with path /
  if failed script "/sbin/check_lvm rootvol" with timeout 7s then alert
  if space usage > 90% then alert
  ...
---

This way it could be possible to combine existing tests with custom 
checks, such as for example in the above text to test state of volume 
manager metadevice (using script) and space usage (using monit built-in 
test. The method will return appropriate event type in the case of 
failure/passed state and event decription and monit will handle the 
defined action. The timeout serves as safety for the case that the 
method will be jammed.


Martin


Michel Marti wrote:
> Hi all,
>
> I'm missing the possibility to use a external script for doing service 
> checks.
> e.g.:
>
> check script myservice with path /usr/local/bin/check-myservice
>   start program = "/etc/init.d/..."
>   stop  program = "/etc/init.d/..."
>   if failed then restart
>
> In this scenario, all exit codes from the "check-myservice" script != 0 
> would be
> threated by monit as "failed".
>
> I wonder if anyone has considered or has started working on such a feature?
>
>
> Michel.
>
>
>
> --
> To unsubscribe:
> http://lists.nongnu.org/mailman/listinfo/monit-general