Re: M/Monit: HTTP 408 Request Timeout

[Martin Pala]

Regarding the port 2812 issues ... you can use unixsocket as an option to TCP 
port for Monit HTTP (added in Monit 5.12 specifically because of Docker 
networking specifics).

Regarding the setup - yes, the classic active-passive cluster (hot-cold) is 
possible.

Regards,
Martin


> On 03 Apr 2015, at 21:31, Thomas Spicer <address@hidden> wrote:
> 
> I had not set connectionTimeout so it is using the default. We are narrowing 
> the issue down to a Docker networking issue. basically, the port (2812) is 
> not being properly opened which would possibley explain the timeout. 
> 
> As for the approach…
> 
> Within the monitrc config file I would set 2 different reporting end points. 
> This would then send an event to both locations to ensure that the M/Monit 
> instance A is the same view as MMonit instance B. The downside, it appears, 
> is that you are replicating the same events and needing to specify multiple 
> collector endpoints in the monitrc config. Rather than hot-hot instances it 
> might be better to have a hot-cold setup to avoid the cache issues you 
> mentioned?
> 
>> On Apr 3, 2015, at 1:08 PM, Martin Pala <address@hidden> wrote:
>> 
>> Hello Thomas,
>> 
>> the request timeout may occur if the client (Monit or GUI client/browser) 
>> didn't complete the HTTP request on time. Default timeout is 30 seconds, you 
>> can modify it in the conf/server.xml file with the "connectionTimeout" 
>> attribute of the <Connector> element.
>> 
>> Note that the mentioned setup will work as long as both M/Monit instance 
>> *don't* share the database (they can use the same database machine, but each 
>> instance needs independent schema/db). M/Monit caches the data extensively, 
>> some data are primarily read from memory so two M/Monit instances sharing 
>> the same database won't provide the same image. If you set two independent 
>> M/Monit instances, Monit can report to both of them (using multiple "set 
>> mmonit" statements), so it will work like a mirror.
>> 
>> Best regards,
>> Martin
>> 
>> 
>>> On 03 Apr 2015, at 15:31, Thomas Spicer <address@hidden> wrote:
>>> 
>>> Greetings,
>>> 
>>> 
>>> We are currently doing a test deployment of M/Monit 3.4.1 and Monit 5.13.
>>> 
>>> In what conditions would "HTTP 408 Request Timeout” appear in the M/Monit 
>>> log? For example:
>>> 
>>> 2015-04-03 13:21:04 [client 10.0.0.222] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:09 [client 10.0.0.222] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:09 [client 10.0.2.33] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:14 [client 10.0.0.222] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:19 [client 10.0.2.33] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:19 [client 10.0.2.33] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:24 [client 10.0.0.222] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:24 [client 10.0.0.222] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:33 [client 10.0.0.222] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:33 [client 10.0.2.33] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:33 [client 10.0.2.33] HTTP 408 Request Timeout
>>> 2015-04-03 13:21:34 [client 10.0.0.222] HTTP 408 Request Timeout
>>> 
>>> The setup looks like this:
>>> 
>>> Load balancer- 001(AWS ELB) -> mmonit-001 -> mysql-001
>>> Load balancer- 001(AWS ELB) -> mmonit-002 -> mysql-001
>>> 
>>> Everything is set for SSL communication, from LB to mmonit to mysql (for 
>>> now)
>>> 
>>> Most things seem to work nicely as events are captured and logged. 
>>> Reviewing the error logs reveals the items above. The monit log looks quiet.
>>> 
>>> I did not see much about this error on the manual or in google searches. 
>>> Any suggestions or tips would go a long way in helping us in our eval.
>>> 
>>> Best Regards,
>>> 
>>> Tom
>>> --
>>> To unsubscribe:
>>> https://lists.nongnu.org/mailman/listinfo/monit-general
>> 
>> 
>> --
>> To unsubscribe:
>> https://lists.nongnu.org/mailman/listinfo/monit-general
> 
> 
> --
> To unsubscribe:
> https://lists.nongnu.org/mailman/listinfo/monit-general