[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFD] External pluggins
Re: [RFD] External pluggins
Wed, 04 Sep 2002 11:55:53 +0200
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3
Jan-Henrik Haukeland wrote:
Request for Discussion:
Theme: External pluggins
I'm not sure about it. I'll try to summarize areas in which i think is
probably good to have possibility to bind some external program:
The intentions of this mail is to start a discussion on a design
choice for monit with regards to support external pluggins or not.
The initial design choice for monit was to create a simple self
contained and autonomous monitoring program with an easy to use,
but comprehensive configuration. The idea was to create a different
and simpler to use monitoring program than the many other monitoring
programs out there that relies heavily on pluggins to do anything.
I still belive that this was and is a good design choice. The
benefits for the users are obvious, he does not have to find and
download X pluggins and install and configure each pluggin.
Instead, everything can be done from one configuration file and
with one monitoring program.
On the other hand it does makes monit a bit unflexible in that we
only monitor general parameters, like the process, the network
connection and a small set of network protocols. On yet another
hand this is often enough, but in the few cases where something
more is needed a simple pluggin architecture could do the trick.
3. Proposal: A plugging architecture
First, I still want monit to be self contained in that all main
monitoring tasks are done in and from monit, like it is today. A
pluggin is only an extension to monit and does not take over any of
the vital monitoring tasks in monit nor any main protocol tests.
My proposal for a pluggin architecture for monit is like The Common
Gateway Interface (CGI) is for a web server. In this setting monit
is like the web server; monit is doing all the main monitoring
stuff as the web server is doing all the main HTTP stuff, but for
special situations a CGI program can be created. This is exactly
the same design philosophy I propose for a pluggin architecture in
monit. Like the developers of a web server we should not care about
the actually CGI program only the CGI protocol as an extension to
I further propose that we model our pluggin architecture after the
CGI model. That is, the server (monit) start an external program,
i.e. a pluggin, so that stdin is used to send protocol information
to the program and output from the pluggin is sent back to the
server. The figure below illustrate this setup:
STDIN + ENVIRONMENT VAR.?
|monit| STDOUT | Pluggin |
The pluggin is created to check a certain service and should simply
report back to monit if the service is ok or not and if not the
action to take. I propose that only 4 action is used, they are;
restart, stop, start and alert.
This is a proposal for a major new design choice for monit and thus
should be voted on by the project committers. If we decide to do
this the details of the CGI like protocol should be discussed and
What do you think?
Maybe we can think about two categories:
a.) monit will initiate the "communication" (for example sends alert
about some event)
b.) external program will initiate the connection (for example thay will
read status of process)
I think that both these categories can be satisfied by supporting
optionaly XML output. For a.) it means that we will support maybe
similar design as Jan described - i think it could be satisfied by
allowing to register 'notification' plugin(s) and monit will send in the
case of event on its standard input message in XML format. For b.) it
means that we maybe could implement optional XML output too (for example
by specifing variable 'output=xml' in http request - default should be
html). If so, it will allow to use monit's httpd as source of process
status and provide interface to manipulate processes on the server.
There could be 3rd party application such as monitoring system
(netsaint/nagios) or managment console that can control all instances of
monit on the network and use it to watch and maintain processes.
Maybe we can make the protocol/testing interface more general to allow
write module for testing anything you want (even with third party
library/API support). It can allow to write any test you want and it can
be easily integrated to monit through its protocol API. Present protocol
API is maybe to closed and i think it will be useful to redesign to
allow integrate such modules. If we do it similar way, we will still
have monit compact enough i think. Disadvantage of this method in
comparision with your proposal is, that it allows to write modules only
3.) CONFIGURATION (part of notes for draft)
Monit could read and mix more configuration sources to build its runtime
environment. There will be precedence from highest priority to lowest:
command_line_options -> local_configuration(such as plaintext) ->
It should be possible to integrate new configuration source into monit.
Simple interface for it based on present configuration language is
described in the draft i'll submit.
When i think about point 1.) again, it seems that we can maybe make from
monit secure replacement for all bugy SNMP implementations. Maybe it
could be possible with general testing API to write modules for checking
and reporting other resources that SNMP watches (such as network
connections, process table, disk usage, etc.)
What about it? (it is maybe trip far outside original RFD :)