monit-general
[Top][All Lists]
Advanced

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

Re: [RFD] External pluggins


From: Martin Pala
Subject: Re: [RFD] External pluggins
Date: Wed, 04 Sep 2002 11:55:53 +0200
User-agent: 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


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


--
To unsubscribe:
http://mail.freesoftware.fsf.org/mailman/listinfo/monit-general
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:

1.) OUTPUT
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.


2.) TESTS

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


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) -> external_sources

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.


4.) MISC.

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 :)

Martin








reply via email to

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