[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some feature notes for monit
Re: Some feature notes for monit
Fri, 09 Jul 2004 23:24:15 +0200
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040704 Debian/1.7-4
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
### Syntax inconsistence: start/stop methods
Wouldn't it be cleaner to write `set start "/etc/init.d/foo"' instead
-1 besides, "set" is a keyword used for global statements
### 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
### 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
Monit TIMESTYAMP test checks mtime && ctime
### Missing check: general lstat(2) variable check
-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
### 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 :)
We can read the return code of the script (=> state) and read the
standard and error output of the script for possible message (=> state
### Missing check: ext2/ext3 attributes (e.g. whether the file is
### Global resource (load avg, memory usage) check
1 Very good idea. It's Christians domain so lets hope he agree :)
### 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.
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
- 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.
### Multiple group membership
- Re: Some feature notes for monit, (continued)