[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: monit unresponsive to status requests?

From: Martin Pala
Subject: Re: monit unresponsive to status requests?
Date: Tue, 26 Jul 2005 10:39:59 +0200
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

We have discussed the modules in the past and decided to not support them. The reason is that monit should be simple, autonomous system, which should depend on as few external programs/libraries as possible to provide high reliability and simple usage. See "Design philosophy" on our main page:

Provided that there will be API for external testing modules, i agree that it could be useful and may integrate with monit well (of course if others will agree :)

The API probably should have at least these features:

1.) when monit execs the testing module, it will wait for:
 - either it to finish normaly (return code?)
- or optional method execution timeout will occure (by default for exmaple 5s) => monit will fire 'method timeout' event

2.) the method have to return all informations that monit needs to set for event, i.e. for example:
 - general method return code (method failed to execute?)
 - service state (service failed/passed?)
 - error level (how bad the state is e.g. critical/warning/info/...)
 - event type (one of event types known to monit)
 - event description (details what happened)

Monit API can handle some method states automaticaly (for example 'method timed out', 'method failed', etc.), otherwise the method will be responsible to specify what happened. The above described method API iterface should be required - in the case that some information is missing, the method is incompatible.

This is just raw image ... what about it?


Randy Bias wrote:
I like this hack, but the problem is that it adds in another process that I have to rely on. It's better if I am only relying on init and monit.


Randy Bias        randy-at-netenrich-dot-com
Director of Application Engineering & Support

On Jul 24, 2005, at 2:08 PM, Martin Pala wrote:

It is possible to use general 'trick' for this by using custom script running from cron for example, which updates the timestamp of some state file.

Monit then checks the timestamp of this file using the timestamp rule, for example:

  check file nfs_proc_count with path /tmp/nfs_state
    if timestamp > 10 minutes then ...

The script running from cron for example each 5 minutes, could be simple, something like:

  if [ `pgrep nfsd | wc -l` -ge 4 ]; then touch /tmp/nfs_state; fi

=> in the case that there are at least four nfs processes, timestamp of the /tmp/nfs_state file will be updated. In the case that there are less then four process, state file timestamp will not be updated and monit will trigger event.


Marco Ermini wrote:

This is what the OpenView sysadmin sometimes did. They have the agent
running an external script using, for instance, Korn shell. In this
script you can put anything, for instance, check that you have at
least 4 Java processes, or grep a log file, or whatever. Then the
result (0 as positive, other values as wrong) will trigger the alarm
or not.

To unsubscribe:

To unsubscribe:

reply via email to

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