monit-general
[Top][All Lists]
Advanced

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

[RFD] External pluggins


From: Jan-Henrik Haukeland
Subject: [RFD] External pluggins
Date: 04 Sep 2002 04:07:43 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)

Request for Discussion: 
Theme: External pluggins


1. Objectives

   The intentions of this mail is to start a discussion on a design
   choice for monit with regards to support external pluggins or not.


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

   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.


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.

   What do you think?



Jan-Henrik




reply via email to

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