[Top][All Lists]

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

Re: Websockets monitoring

From: Martin Pala
Subject: Re: Websockets monitoring
Date: Wed, 5 Mar 2014 11:28:19 +0100


it seems that your websocket server doesn't support ping/pong (part of 
websocket specification: RFC 6455) and instead sent some text frame in response 
to ping ... either the text frame contains some error description, websocket 
ping request is prohibited or the server is not RFC 6455 compliant.

The problem can be in the test configuration ... the version 13, origin 
""; works with the demo echo websocket server operate by Each websocket application has its own version and 13 may be 
invalid in your case. Also the origin is part of websocket security model and 
origin ""; is basically settings for's 
service ... not general value - but if it was not accepted by the server, it 
should return 403 error as response to HTTP upgrade request, which it didn't 
(101 was received, otherwise there will be different error in log).

The demo with "location" works for 
ws://, but their echo test doesn't use ping - it 
sends just text frame ... such test is not generic and may fail in other 
websocket implementations (connect+ping/pong+close should be generic for every 
RFC compliant server).

We can simplify the test and rely only on websocket connection (http upgrade 
request) + websocket close ... this should work on all websocket servers, even 
those which don't support ping/pong.

Please can you get a network trace of the test? You can use for example 
tcpdump/tshark/wireshark/snoop, tcpdump on the machine where Monit is running:

        tcpdump -s 0 -i any -w websocket.pcap port 10301

If there is also regular traffic which you don't want to expose to mailing 
list, either filter out only the Monit session packets or send the file 
directly to me.


On 05 Mar 2014, at 09:32, Mehul Ved <address@hidden> wrote:

> Hi Martin,
>  I tried using the new version of monit but it fails on `monit validate` for 
> websockets
> $ which monit
> /usr/local/bin/monit
> $ monit --version
> This is Monit version 5.8
> Copyright (C) 2001-2014 Tildeslash Ltd. All Rights Reserved.
> The lines I've added:
> if failed host port 10301 protocol websocket
>    host ""
>    request "/"
>    origin "";
>    version 13
>    then alert
> $ monit validate --verbose
> 'wsserver' zombie check succeeded [status_flag=0000]
> 'wsserver' succeeded connecting to INET[] via 
> 'wsserver' failed protocol test [WEBSOCKET] at 
> INET[] via TCP -- WEBSOCKET: pong error -- 
> opcode 0x1
> Using location ws:// in location box on 
> works perfectly. It responds with "who" which is 
> correct. Is there a way to set send/expect to check for the correct response?
> ________________________________________
> From: address@hidden <address@hidden> on behalf of Martin Pala 
> <address@hidden>
> Sent: Monday, March 03, 2014 2:29 PM
> To: This is the general mailing list for monit
> Subject: Re: Websockets monitoring
> Hi,
> we have implemented the websocket protocol test, example usage:
> check host with address ""
>    if failed port 80 protocol websocket
>      host ""
>      request "/"
>      origin "";
>      version 13
>    then alert
> The test connects to websocket, performs ping/pong test and closes the 
> connection.
> If you want to test it, you can get the development Monit version here: 
> Compilation:
>        tar -xzf master.tar.gz
>        cd tildeslash-monit-*
>        ./bootstrap && ./configure && make
> The monit binary will be in current directory, you can install it to 
> "/usr/local/bin" using "make install"
> Regards,
> Martin
> On 24 Feb 2014, at 07:23, Mehul Ved <address@hidden> wrote:
>> Hi,
>>  I have a node.js service that works as a websocket server. I am working on 
>> monitoring it using monit. I haven't been able to find any information about 
>> using websockets with monit either in the group archives or using google 
>> search. Has anybody worked on this before?
>>  Is it possible to monitor websockets in monit currently without adding in a 
>> websocket client script in between? I can definitely do that but wanted to 
>> check if there's a better way to do it without any additional component.
>> --
>> To unsubscribe:
> --
> To unsubscribe:
> --
> To unsubscribe:

reply via email to

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