[Top][All Lists]

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

Re: Some feature notes for monit, volume III

From: Jan-Henrik Haukeland
Subject: Re: Some feature notes for monit, volume III
Date: Wed, 14 Jul 2004 18:56:54 +0200

On Jul 14, 2004, at 5:50 PM, Vlada Macek wrote:

### Monit monitoring

Is there some way to detect that monit is successfully running? I would
like to ensure (from the cron) that the monit process does not merely
exist, but actually does the checks it should.
That way I would have a protection of cron-monit pair in both directions
(checking the cron's log timestamp from monit).

One solution that comes to my mind is for monit to touch the file
/var/run/monit.touch every cycle... monit.touch could then be checked by
`find ... -mmin +` on Linux. Another solution would be to write
"--MONITMARK--" log entry every, say, 10 cycles (or configurable time)
to the log output (whenever it's syslog or own logfile).

This catch 22 situation has been discussed before and I think that the conclusion was to run monit from init (/etc/inittab). See also the FAQ for rationale. A corollary was recently discussed on this list, i.e. that monit may and should start rc-scripts. Although this should work without to much problem now, it would help to have a way to specify the start order of daemons. We will add this to monit..

### Service textual comments

The monit web or e-mail output may sometimes be (temporarily) read by
nontechnical people. Attaching a comment to each service explaining what
is this item or exactly what to do in case of the failure may be handy.
What about something like this:

check file ... "/proc/mdstat"
    desc "Disk array check. In case of any failure, please contact any
admin ASAP! Telephone..."

You may specify a special mail format per service and I think this should cover this request?

### Statistics

There are special utilities that gather statistical data from various
parts of UNIX systems. MRTG, snmpd are examples. But when I already run
monit on my server and it is periodically getting most of this data I'm
interested to become graphs possibly, isn't it unnecessary to run
another daemon just to do a duplicate get-this-valueset job?

I admit that it's tempting to add stuff like this to monit. However I think this is best served by another program. This way monit stays orthogonal to it's main purpose without to much bloat. We plan on extending m/monit to handle statistical data and presentations. I.e. monit only post events to m/monit which will store the information in it's database and handle the presentation.

### Refactoring of the HTTP output, unify

There is a separate set of output routines for HTML and TEXT/XML in
http/cervlet.c. I believe the simple XML output was originally added for communication with the m/monit to pass the true/false information about each service. The goal was not to provide an exhaustive information.

You are right about that assumption.

I think it would be much better to unify functions that read RAM structures to one skeleton and call the tag printing routines in accordance to the format requested. This way all formats would provide the same set of information and there is only one code to maintain.

Excellent suggestion. The design would be somewhat similar to
[XML->XSLT->to whatever] which is a good model.

If the core developers will tell me, that they like it
and that such change would make it to their monit, I'm willing to code
it. :-)

I like it and speaking for myself I will strongly support this plan. The current code for output is messy and refactoring this according to your design proposal will certainly improve the code. In other words here is my +1 vote for your suggestion. Can the other commiters please cast their votes on this proposal also. I.e. if we will accept a patch as outlined.


reply via email to

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