Re: Some feature notes for monit

[Martin Pala]

Jan-Henrik Haukeland wrote:
> First, thanks for a well presented and constructive email. We need new 
> ideas to continue evolve monit. However we are all non-paid volunteers 
> and work on monit in our spare time so development tends to be 
> interest-based and not always what (others think) are important for 
> monit. Suggestions are welcome and suggestions backed up by code 
> (patches) are even more welcome and more likely to make it into monit :)
>
> Others have comment on your mail and I just thought I should mark those 
> suggestions I would like to put on our TODO list 
> (http://www.tildeslash.com/monit/next.html) where 1=ok, 0=no opinion 
> -1=no. If the other commiters could be so kind and do the same we may 
> have a consensus on what to add.
>
>
> On Jul 7, 2004, at 5:40 PM, Vlada Macek wrote:
>
> > ### MiB, GiB, KiB... units
>
>
> -1

-1

> > ### Syntax inconsistence: start/stop methods
> >
> > Wouldn't it be cleaner to write `set start "/etc/init.d/foo"' instead
> > of `start="/etc/init.d/foo"'?
>
>
> -1 besides, "set" is a keyword used for global statements

-1

> > ### Mailserver must listen on port 25
>
>
> +1 for flexibility but not very important in my book. Although 
> server:port is a good format I agree with you that we should be 
> consistent and use:
>
> >     set mailserver first.mail.srv port 8025
> >     set mailserver second.mail.srv            # usual port 25

+1

> > ### Access time changed by checks
> >
> > Does monit leave atime of checked fs objects intact?
>
>
> 0 Is atime changed by monit?

0 for now ... but in the case that monit will support atime test, it 
makes sense to keep the the access timestamp across checksum tests

> > ### Missing check: TIMESTAMP checks mtime only
>
>
> 0

Monit TIMESTYAMP test checks mtime && ctime

> > ### Missing check: general lstat(2) variable check
>
>
> 0

-1 ... i preffer the addition of particular tests for given parameters. 
These atomic tests then can be joined if needed to validate all 
parameters as well as they can be used as standalone tests where needed. 
Following tests should be sufficent to add:

- device id
- inode id
- link counts
- access time

> > ### Untight permission check
>
>
> 0

0

> > ### Ability to run an arbitrary command and check:
> >     - its return code in the expression (if retcode != 1 then alert)
> >     - constant and variable checksum of its stdout
> >     - send to stdin/expect from the stdout (like in the host check)
> >     - send to stdin/checksum of the stdout
>
>
> +1 I see your point and it's a good point, however this can be much 
> work, touching on main parts of monit. I think you can do much of the 
> functionality today by calling a shell-script in exec and do the stuff 
> there. But yes it's cleaner to incorporate this in monit, so I'm in 
> favor of the suggestion. The work involved means it will not be high on 
> the priority list, but it should be on the todo list as something 
> someone can do sometime. (Do you volunteer :)

+1

We can read the return code of the script (=> state) and read the 
standard and error output of the script for possible message (=> state 
description)

> > ### Missing check: ext2/ext3 attributes (e.g. whether the file is
> > still immutable)
>
>
> 0

0

> > ### Global resource (load avg, memory usage) check
>
>
> 1 Very good idea. It's Christians domain so lets hope he agree :)

+1

> > ### Join CHECK FILE and CHECK DIRECTORY together
>
>
> 0 Hmm, although everything is a file on unix there is a conceptual 
> difference between file and directory that can be good to separate(?). 
> But having a size and checksum test for a directory is a good idea.

-1.

Present configuration provides possibility to support different tests 
subset for each object type. For example directory has no size or 
checksum tests (it will be bad to allow unsupported test to be defined 
in controlfile for directory monitoring service type).

Based on service type specification (file or directory) is monit 
automaticaly testing the object type too (i.e. file must be regular file 
and nothing others).

The syntax is also more clean - file, directory or even device is 
identified by inode type => merging some types and some not is not good 
solution i think.


> > - I propose to print all XML values in the most technical form for
> > possible later processing <uptime>43m</uptime> is directly
> > displayable, but <uptime>2585</uptime> would be much better!
>
>
> +1 Good point

+1

> > - It may be nice to return instant systemwide resource values
> > mentioned once above (uptime since boot, load averages, memory usage,
> > IO, VM...) in XML and perhaps in HTML too.
>
>
> Exactly, +1.

+1

> > ### Multiple group membership
>
> +1

+1


Martin