monit-general
[Top][All Lists]
Advanced

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

Sure!

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

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.

Possible!

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

See my license worries above.

CHopp


-- 
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
                             pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/





reply via email to

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