[Top][All Lists]

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

Re: Some feature notes for monit

From: Martin Pala
Subject: Re: Some feature notes for monit
Date: Fri, 09 Jul 2004 23:24:15 +0200
User-agent: 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 ( 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
of `start="/etc/init.d/foo"'?

-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 description)

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



### 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.

Exactly, +1.


### Multiple group membership




reply via email to

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