Re: [RFD] External pluggins

[Christian Hopp]

On 4 Sep 2002, Jan-Henrik Haukeland wrote:

Hi!

(...)

> 2. Background
>
>    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 have used netsaint for a while and it was really a mess with all
those plugin and the dependencies.

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

Monits plus is that is depends on nearly nothing.  We know if the
process is down or not.  But if there are plugin you only know that
the plugin says "whatever".  You never know whether it is a problem of
the plugin or the service.

I think monit should focus on the main and important services which
have to run in any case.  It is not monit's task to check what cron
jobs could do.

Monit should be kept small... it took me a while to see it.  If you
integrate it in your system you have to be sure that it works.

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

Yep.

>    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
>    the server.

But the main difference is... the cgi can send after the header
whatever it wants.

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

What happens it the plugin times out... a problem of the service... a
problem of the plugin... should the plugin start again???

> 4. Summary
>
>    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
>    decided upon.

I think we would give up monits uniq and good design in order to be like
other monitoring systems.

-1 for plugin support.

Christian



-- 
Christian Hopp                                email: address@hidden
Institut für Elektrische Informationstechnik             fon: +49-5323-72-2113
Technische Universität Clausthal                         fax: +49-5323-72-3197
  pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/chopp.key.asc  (2001-11-22)