[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for a new "script" service type
From: |
Martin Pala |
Subject: |
Re: Request for a new "script" service type |
Date: |
Tue, 21 Dec 2004 21:18:41 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5 |
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