[Top][All Lists]

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

Re: [monit] Question about cpu monitoring and "expect" behaviour

From: Jan-Henrik Haukeland
Subject: Re: [monit] Question about cpu monitoring and "expect" behaviour
Date: Wed, 11 Mar 2009 16:11:46 +0100

On 11. mars. 2009, at 13.50, Sébastien Wacquiez wrote:

So I tryed to use something like this :
if failed host localhost port 80
    send "GET /blablabla HTTP/1.0\r\n"
   expect "(.|\n){5000}"

If your server is speaking HTTP proper, the correct way to send a HTTP request is to terminate with a blank line. Your regex does not parse either. If you want to ensure that each response line is at least 10 bytes long you can use something like:

 send "GET /blablabla HTTP/1.0\r\n\r\n"
 expect "[^\\n]{10,}"

Note that this will trigger on blank lines and a better option may be to search for a token returned from the server.

But it's not working. It's not working either with the "content"
checking of an http check.

That should work, but note that content checking is for the response body and does not test HTTP headers. The above send/expect on the other hand will test headers also.

After some debugging, I found that monit
seems to stop himself at the first "\0" it found ... Is this the
expected beaviour ?

No, only when reading HTTP headers which are supposed to stop with \r \n. Maybe the server did not send anymore data? Older versions of Monit _did_ use readline in expect which can stop on \n or \0 so to be sure you may want to update to Monit 5.

Last question, about monit communication with mmonit : there is lots of
plugins for other monitoring apps that can parse the monit webpage to
centralise status (like nagios) ; I suppose that monit and mmonit share an API that could simplify those plugins by removing the need of parsing html data. Is this API will be stable and documented, or do you plan to
reserve it for m/monit interaction ?

It is well known that Monit can emit XML and I would guess that any third-party plugin already use this XML format. The XML is easily available by using a format parameter to a Monit request. For instance, http://localhost:2812/_status?format=xml

M/Monit use XML emitted by Monit. The XML message format is fairly stable, but may or most certainly will change in the future.

Best regards


reply via email to

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