[Top][All Lists]

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

Re: Some feature notes for monit

From: Jan-Henrik Haukeland
Subject: Re: Some feature notes for monit
Date: Fri, 9 Jul 2004 03:28:46 +0200

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


### Usability: Hashes on the monit command line

+1 Good idea, most unixes has this functionality already, but not all. For example my OS X does not. Another pluss is that this cost little since we have the functions in monit. I also like your suggestion for output:

An example:

    $ monit -H < /etc/passwd
    MD5 (stdin) = 5676cffe1b85f738ad53bc8fcf4075f5
    SHA1(stdin) = a9e98b7aa950d5cca495f9c83c357360005516b2

### Syntax inconsistence: CERTMD5

+1 It's a documentation issue, openssl handles both.

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

### Static binary linking

See Christian's response

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

### Missing check: TIMESTAMP checks mtime only


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


### 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 :)

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

### XML output
- As I noticed, currently only one kind of monit status page is in
XML. More would be great!

more may come when we continue work on m/monit

- Minor bug: As Content-Type, _status?format=xml returns text/plain,
should be text/xml.

Yep, Thanks

- 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. (HTML though will be the output to monit's web interface.). If you would like to propose (write) a suggestion for a XML schema it would be interesting. I'm currently stuck with what we have.

### Multiple group membership


Here it is. I've some more notes prepared, but it is enough for now.

If you have more stuff it's very welcome.

Jan-Henrik Haukeland

reply via email to

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