Re: Some feature notes for monit (XML mock-up)

[Vlada Macek]

Jan-Henrik Haukeland wrote:

> First, thanks for a well presented and constructive email. We need
> new ideas to continue evolve monit. However we are all non-paid
> volunteers and work on monit in our spare time so development tends
> to be interest-based and not always what (others think) are important
> for monit. Suggestions are welcome and suggestions backed up by code
> (patches) are even more welcome and more likely to make it into monit
> :)

Thanks, anyway it's great. I'll try to contribute better in the future. :-)

>> ### Usability: Hashes on the monit command line
>> ### Syntax inconsistence: CERTMD5

Solved. You guys rock! :-) Thank you.

>> ### Access time changed by checks
> 0 Is atime changed by monit?

Yes, I've checked it. Checksum computation changes access time of the file.

>> ### XML output - As I noticed, currently only one kind of monit
>> status page is in XML. More would be great!
>
> more may come when we continue work on m/monit

Now I think there can be only one XML page with all the status information.

>> - It may be nice to return instant systemwide resource values
>> mentioned once above (uptime since boot, load averages, memory
>> usage, IO, VM...) in XML and perhaps in HTML too.
>
> Exactly, +1. (HTML though will be the output to monit's web
> interface.). If you would like to propose (write) a suggestion for a
> XML schema it would be interesting. I'm currently stuck with what we
> have.

I'm attaching my XML mock-up. There are some ideas about what could be
in such technical output. I imagine an ideal state, where the
information is generated by one kind of C function for all XML, TEXT and
HTML output. That way the reported dataset will be the same for all
three forms (HTML still divided to pages, XML and TEXT would return all
on one request). But I'm afraid it's not your original goal.

Because of this I've not included detailed <service> information (such
as UID, checksum, free inodes...) in my mock-up, before the feature goal
is pronounced. I would definitely like them there so m/monit (or
anything) could store as much information as it can upon signal for
historical browsing. By signal I mean detecting an alert and
automatically request the status upon change on monit server an store
it. The status does not need to be accessible when the admin finally comes.

Vlada

<?xml version="1.0" encoding="iso-8859-1"?>
<monit>
        <system>
                <hostname>dilbert.hisoffice.org</hostname>
                <uptime>654434</uptime>
                        <!-- seconds since system boot              -->
                <load>0.03 0.12 0.10 </load>
                        <!-- it's easily parseable everywhere       -->
                <vmusage>40</vmusage>
                        <!-- virtual memory (RAM+swap) usage in %   -->
                <timestamp>1089375165</timestamp>
                        <!-- system clock and XML timestamp         -->
        </system>
        <server>
                <version>4.3.1-beta1</version>
                <uptime>2585</uptime>
                        <!-- seconds since monit daemon (re)loaded  -->
                <pollperiod>5</pollperiod>
                <checksum 
type="sha1">c37f044e514a3ad34941db0407c1ad435f8781d3</checksum>
                        <!-- of the monit binary if available       -->
                <ledalert>1</ledalert>
                <beepalert>1</beepalert>
                <controlfile>
                        <path>/etc/monit.d/dilbert.monitrc</path>
                        <checksum 
type="sha1">cced5153f6d46b8873fe7272e14bdcdbdf9e5361</checksum>
                                <!-- after all includes             -->
                        <timestamp>1089370040</timestamp>
                                <!-- last mtime touch               -->
                </controlfile>
        </server>
        <service type="Process">
                <name>cron</name>
                <status>1</status>
                <monitored>1</monitored>
                <active>1</active>
                <group>daemons</group>
                <timestamp>1089375160</timestamp>
        </service>
        <service type="Process">
                <name>syslogd</name>
                <status>1</status>
                <monitored>1</monitored>
                <active>1</active>
                <group>daemons</group>
                <timestamp>1089375144</timestamp>
        </service>
        <service type="File">
                <name>proftpd_conf</name>
                <status>1</status>
                <monitored>1</monitored>
                <active>0</active>
                <timestamp>1089375020</timestamp>
        </service>
        <service type="File">
                <name>passwd</name>
                <status>1</status>
                <monitored>1</monitored>
                <active>0</active>
                <timestamp>1089375020</timestamp>
        </service>
</monit>

signature.asc
Description: OpenPGP digital signature