[Top][All Lists]

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

Re: features to work on - summary and request for discussion

From: Davide Dente
Subject: Re: features to work on - summary and request for discussion
Date: Sat, 07 Feb 2004 13:15:01 +0100

From:   Martin Pala
Subject:        features to work on - summary and request for discussion
Date:   Fri, 06 Feb 2004 22:30:16 +0100

> (3) web output extension:
> (3a) snmp (needed for SNMP support) - example:
> http://localhost:2812/_status?output=snmp
> (3b) xml (needed for m/monit) - example:
> http://localhost:2812/_status?output=xml

Hello everybody,

we are using monit here and we like it very much.

I did have a suggestion regarding some of the work proposed. We already
have here an home grown web framework able to receive updates and show
the status of various checks; more or less what is proposed with m/monit,
but it is able to be updated remotely in several kinds of different ways.

We would like to write a filter that is able to query the various remote
instances of monit and update our framework. I first was considering
parsing the HTML output, but it is a bit too messy. Then I did start
writing a perl script to be executed on every host that is able to parse
the output of "monit status" and sending the result to the central
application; doable, but more fragile and you have to keep the script
(and the scheduler/cronjob) in sync and configured everywhere.

The proposed XML status page solves my problems: the parsing script and
the scheduling policy can be kept in a central location, and the output
should be easily readable.

But may I suggest another output extension ?

(3c) text - example:

That page should just show the same output of "monit status", which is
already easy to parse. Should be quick to implement, and it could be a
test bed for the other, more advanced output modes. Unfortunately, I am
no C programmer; but if this output is available I can promise a Perl
module for the easy retrivial and parsing of this information.

The only change that need to be made to the "monit status" output should
be adding at the start the version of the monit daemon (as shown by
"monit -V"). This way, the central server could be able to query
different versions of monit on the same network.

It is really just a small suggestion; in the end, this output mode is not
that different from the proposed XML mode.

Anyway, thank you very much to the developers for monit; it has really
made my job a lot easier.


-- - I mean, what is it about a decent email service?

reply via email to

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