Re: FYI: monit status output

[Davide Dente]

On Tue, 17 Feb 2004 15:12:41 +0100, "Jan-Henrik Haukeland"
<address@hidden> said:
> "Davide Dente" <address@hidden> writes:
> 
> > A simple suggestion: if you add to both the XML and the text output
> > the version of the monit daemon (i.e., 4.1.1 or 4.2) it will be
> > easier in the future to write parsers that are able to parse the
> > output from multiple hosts.
>
> I understand this can be a problem for you guys since you collect the
> status, but it's a drag to support both versions. How about doing the
> changes in the collector system and support both versions there?

Sorry, I wasn't able to explain myself well enough.

Let's say that monit 4.2 will go out with an XML output.

Then you realize that you want to change something in the output, maybe
adding support for some new feature, and monit 4.3 will be shipped with a
slightly modified XML output (for example, a new tag <foo>).

And then in monit 4.4, or 5.0, or any other future version, you will have
to introduce some other changes.

Now m/monit (and any other collector frameworks) will need a way to
handle the possibility that not all the monit daemons present in a given
environment will have the same output format.

The easiest way I see to handle that is simply to add a <version> field
in the "header", something like this:

> <monit>
>         <monit-server>
>                 <uptime>String</uptime>
>                 <version>String</version>
>         </monit-server>
>         <service>
>                 <type>process</type>
>                 <name>apache</name>
>                 <status>1</status>
>                 <monitored>1</monitored>
>         </service>
>         [...]
> </monit>

This way m/monit will be able to know what format to expect. When
collecting the output from monit daemons version 4.2, no <foo> tag is to
be expected. When collecting for a daemon version 4.3, the <foo> tag is
expected and should be processed.


I think that this change could make things a bit easier down the road.


regards,
david

-- 
http://www.fastmail.fm - Accessible with your email software
                          or over the web