[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


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

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/
  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.


Michel Marti wrote:
Hi all,

I'm missing the possibility to use a external script for doing service checks.

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?


To unsubscribe:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]