[Top][All Lists]

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

Re: Monit 4 enhancement requests

From: Martin Pala
Subject: Re: Monit 4 enhancement requests
Date: Wed, 24 Sep 2003 09:48:40 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030908 Debian/1.4-4

Interesting :)

ad. 1.) ICMP ping support - already scheduled, i will look on it. I think i can start the implementation next week.

ad. 2.) IPv6 support - it could be interesting (but not for me for this moment)

ad. 3.) daemontools - it could be good to test it and add the hint to documentation. I can do it.

ad. 4.) alert limitation on x of y cycles - this could be usefull too, but in such case we need to discuss timeout statement relationship. I think in the case that we will implement this, we need to modify tests to not change the expected value during monitoring (for example like checksum statement does) and implement general timeout statement syntax + requested alert cycle limitation. The user then can choose - either to timeout the service check after x of y events occured or skip some cycles. If neither of these statements will be specified, monit will send alert on each cycle. The syntax can be commonized to, for example:

IF x {event[, event]...} WITHIN y CYCLES THEN {timeout|alert}

=> you can choose for each type of event ratio when to alert or when to timeout. Event is specification of the event type (such as restart, start, timestamp, etc.) If you will not specify alert ratio for particular events (for example restart) or at all, by default monit will send alert every cycle, which is equivalent to:

if 1 restart within 1 cycle then alert

The advantage is, that you can set timeout watermark timeout or send alerts for service tests independently for each event type. You can combine it as well, for example:

For process service types:

if 2 restart within 2 cycles then alert
if 5 restart within 10 cycles then timeout

For file service types (to send alert each second cycle on timestamp and timeout in the case that the erronrous condition remains for 6 cycles or timeout immediately in the case of critical event):

if timestamp > 1 hour the alert
if 2 timestamp within 2 cycles then alert
if 6 timestamp within 6 cycles then timeout
if 1 checksum, uid, gid, permission within 1 cycles then timeout

If you will not specify timeout statement, you will receive the alert either every cycle or as limited by above alert condition statement.

What do you think?


Jan-Henrik Haukeland wrote:

FYI: Some feature requests. I think that requests 1 and 4 are the
interesting once, 1 is already in planing by us.


Monit 4 enhancement requests
address@hidden (Klaus Alexander Seistrup)
Tue, 23 Sep 2003 20:18:17 +0200
Jan-Henrik Haukeland <address@hidden>

[ I hope this email has reached the right mailbox, I couldn't seem
 to find an appropriate mail address for requests and bug reports. ]


I have recently installed monit v4.0, and while this version is a big
improvement over the v3-series, there's still room for enhancements.
In no particular order I'd like to see the following features in monit:

 ?  ICMP/ping support
Currently monit supports TCP and UDP. I'd very much like to
    be able to ping hosts also.

 ?  IPv6 support
In addition to TCP, UDP and ICMP, please support TCP6, UDP6
    and ICMP6.

 ?  Support for running monit under d?montools
Instead of running monit under init or as a regular d?mon, I
    prefer to run monit under DJB's d?montools or Pape's runit
    suite, and of course I can do so using the -I switch of monit.
    What I'd like to see, though, is monit writing log messages to
    [a line buffered] stdout so that they're captured by multilog
    (d?montools) og svlogd (runit).

 ?  Alert limitation
When services that are checked often fail, monit spews a slew
    of alerts to the designated mailbox.  I'd like to see e.g. an
    "alertevery" keyword, that takes a time specification as its
    argument.  When != 0, monit should send out an alert only once
    per time period.

Thanks for making monit available to the community!


 // Klaus


Since this is a feature list, I would also like to add these
suggestions. Just for discussion and I'm not sure about the relevance
of all of these:

1) Support more than on SMTP server (I think this was suggested before?)

  If monit cannot connect to a SMTP server it should have a list
  other smtp server to try. Changes in the mail server statement:
          SET MAILSERVER [server]+
  statement example:
          set mailserver,,

2) Extend the timeout statement to timeout a service for a configured
  period and then try again. Such as (extension in capital letters)

  IF 2 restarts within 3 cycles then timeout and START MONITOR AGAIN

  This could be *one* solution to the "Alert limitation" requested

3) On a same note; if a service was stopped, especially because of
  machine load, then monit should be able to start it again when
  the load goes back to normal again. E.g. (extension in capital

     if loadavg(5min) greater than 3.0 for 2 cycles then stop

  Or to stop a service for 5 minutes:

  check process apache ..
if cpu > 99% for 3 cycles then stop AND RESTART AFTER 5 MINUTES

4) Introduce time triggering service checks. Kind of a sub-set to
  crond(8). That is, only check a service at a certain time *not* in
  each poll cycle (again, extension in capital letters).
check file access.log with path /usr/local/apache/logs/access.log
           AT 04:00 # Only run this check at 4 AM.
if size > 100 MB then exec "/usr/sbin/logrotate -f apache"


To unsubscribe:

reply via email to

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