Re: FYI: m/monit - centralized monitoring

[Martin]

----- Původní zpráva -----
Od: Jan-Henrik Haukeland <address@hidden>
Datum: Čtvrtek, 6.listopadu 2003 - 12:27 odp.
Předmět: Re: FYI: m/monit - centralized monitoring

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

I preffer general interface for such applications integrated to monit. It need 
not to be m/monit only solution - general XML interface (as you mentioned 
bellow) could be good choice and i preffer such solution (such as output's mime 
type specification - content type requested by client). The configure option 
then need not to be "--with-mmonit" but more general "--with-xml", etc.

Then monit can present the same data in different formats (in addition to 
present text/html possibly new types text/xml, text/plain, etc.) => the 
presentation layer will adjust the output.

Here is my +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.

I think this change is very usefull generaly. Recently on mailinglist were few 
messages addressing exactly this point. It is good to know that error condition 
is over and that you can sleep peacefully :)


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

I think it is quite good

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