Re: Some feature notes for monit, volume III

[Jan-Henrik Haukeland]

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.

regards
Jan-Henrik