Re: Monit 4 enhancement requests

[Martin Pala]

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?

Martin

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.
>
>  
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Monit 4 enhancement requests
> From:
> address@hidden (Klaus Alexander Seistrup)
> Date:
> Tue, 23 Sep 2003 20:18:17 +0200
> To:
> 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. ]
>
>
> Hi,
>
> 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!
>
> Cheers,
>
>  // 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, mail.tildeslash.com, mail.foo.bar
>
> 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
>   AFTER 1 HOUR.
>
>   This could be *one* solution to the "Alert limitation" requested
>   above.
>
> 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
>   letters):
>
>      if loadavg(5min) greater than 3.0 for 2 cycles then stop
>         UNTIL LOADAVG(1MIN) IS LOWER THAN 1.0 THEN START
>
>   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:
> http://mail.nongnu.org/mailman/listinfo/monit-general