Re: monit 4.3, what event for generic protocol failure?

[Jan-Henrik Haukeland]

"Tom O'Brien" <address@hidden> writes:

> Here's a portion of my monit configuration:
>
>   if failed port 1033
>     send "AG_PROBE\n"
>     expect "AG_OK\n"
>   with timeout 15 seconds then alert
>   alert address@hidden { timeout connection checksum nonexist }
>
> I get alerts when I cannot connect to port 1033, but when the server
> program is not calling accept(), I get the following logs, and no
> alerts.
>
> May 17 11:00:08 kanplay monit[4709]: GENERIC: successfully sent:
> 'AG_PROBE '
> May 17 11:00:23 kanplay monit[4709]: GENERIC: error receiving data --
> Resource temporarily unavailable
> May 17 11:00:23 kanplay monit[4709]: 'guardian' failed protocol test
> [generic] at INET[localhost:1033].
>
> When I change my alert definition to:
> alert address@hidden
>
> I do get an alert, however the $EVENT is set to "Connection failed",
> which is the same as the $EVENT when port 1033 was not available.
>
> What is the event definition that triggers the alert?

I do not think this has anything to do with events and alerts, the
setup you have looks good. To me, it looks like the server you send
the expect string to does not understand that it has received a full
request and is waiting for more input and does not send back a
response. Therefor nothing is sent back to monit and the connection
timeout, hence the "Resource temporarily unavailable" error. (Of
course this is what would happen if the server has an internal error
and cannot process a request, but assuming the server's processing
machinery works..)

This is consistent with your problem description. If you run monit in
debug mode (i.e. monit -Iv) you can probably see in the console that
the server _never_ sends back a response which the expect statement
can compare.

I don't know what protocol you are testing, but if it's anything like
a standard text based Internet protocol, you need to terminate a
string sent to the server with "\r\n" not just "\n". If the server
does not handle one-by-one line but waits for a full request (such as
in the HTTP protocol, where a request ends with "\r\n\r\n") you must
also make sure that you send a full request to the server before you
can test an EXPECT response string.

Hope this helps 

-- 
Jan-Henrik Haukeland