[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.
regards
Jan-Henrik