[Top][All Lists]

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

Re: FYI: m/monit - centralized monitoring

From: Christian Hopp
Subject: Re: FYI: m/monit - centralized monitoring
Date: Thu, 6 Nov 2003 15:21:56 +0100 (CET)

On Thu, 6 Nov 2003, Jan-Henrik Haukeland wrote:

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

Dont like these forking projects.  At the end you might have an own
monit dist just for m/monit with additional maintenance.  I would
prefer things below...

> 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

I dont think it is necessary... if we integrate a simple xml
interface, we might be able to get rid of the "text" transmission for
the cli.  Instead it retrieves the xml data and displays the specific

Do you have a tight xml lib in mind or should we parse it
ourselves... shan't be a big deal.

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

Actually it is a tool for 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.

Aren't there any conflicts having code depending on a proprietary
library in our dist?  And aren't there conflicts having m/monit in GPL
with zild being non open source?

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

As long as there are no license problems would give it +1.

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

S.a. it should replace monit's clear text transmission.

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

Isn't snmp the protocol of choice for this application?

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

monit-zild or monit-mgr.

> [3] Except zild cannot be checked into 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)

See my license worries above.


Christian Hopp                                email: address@hidden
Institut für Elektrische Informationstechnik             fon: +49-5323-72-2113
TU Clausthal, Leibnizstr. 28, 38678 Clausthal-Zellerf.   fax: +49-5323-72-3197

reply via email to

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