Re: FYI: m/monit - centralized monitoring

[Jan-Henrik Haukeland]

Thanks for the feedback Christan and Martin. I was thinking, Christian
is right about that there will be necessary to do some small
changes[1] in monit to integrate it with m/monit[2]. First I thought
about creating these changes myself in a separate monit distributed
with m/monit to avoid messing up *our* monit, but this is not an
optimal nor flexible soultion.

What do you think about folding m/monit into the monit project in this
way:

  1) m/monit is licensed as GPL (but I would still like to have the
     copyright for m/monit if you are comfortable with this?)

  2) The m/monit integration code changes is part of the offical monit 
     code but will be a configure option at compile time. E.g. 
      ./configure --with-mmonit

  3) m/monit is just an extra module/program to monit and is
     distributed from monit's homepage and discussed on this mailing
     list and so on. In effect m/monit *is* monit.

Having m/monit as part of our monit project will, I feel, be a good
thing and complement monit. The m/monit C servlet source code should
also be part of the monit CVS repository[3], this way you can pitch in
and change code as usual, when you have time and can contribute.

What do you think? My vote on this is obviously +1 :)


BTW If anyone will like to take m/monit for a test spin (note this is
a horizontal GUI prototype for now with **no** functionality) you can
download the software from here: 

               http://www.tildeslash.com/monit/mmonit/

(There is also a hello world C servlet included which you can look at
and hack to see how C servlet source code may look like. m/monit will
consists of several such C servlets for implementing the m/monit
functionality)


[1] The changes I can think of now in the official monit are:

    a) Add an XML output format when asking about monit status so it's
       easier for m/monit to parse the status output.

    b) The alert module is extended with a HTTP POST so alerts sent
       via SMTP can also be posted to m/monit and saved in m/monit's
       history database. (I know I also mentioned collecting history
       data via SMTP but this may be in a later version)

    c) There must (probably) be sent an alert when a service is
       comming up also so m/monit's history database can report a
       service downtime *and* uptime.

[2] The name m/monit is just something I came up with (where m/ stands
    for meta or many or something like that). Suggestion for a better
    name are welcome. (or maybe it's not that bad?)

[3] Except zild cannot be checked into savannah.gnu.org since it's
    not GPL. But that's only the zild binary, the rest of m/monit
    directory tree can be checked in. (See the mmonit.tgz above)

-- 
Jan-Henrik Haukeland