Extreme data in upstream response time when proxying ws://

[williamchong]

After little investigation the problematice request is GET /socket.io/?EIO=3&transport=websocket
Is there anyway we can filter ws:// out of the metric?

[dedm]

Hi @williamchong007!

May I kindly ask you to provide a little bit more details?
Please, show me the log line for this request and the log format for that line.

Thanks in advance!

[williamchong]

I have another similar log line:

xxx.xxx.xxx.xxx - - [03/Feb/2017:11:49:25 +0000] "GET /socket.io/?EIO=3&transport=websocket HTTP/1.1" 101 2945 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.21 Safari/537.36" "xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx" "xxx.com" sn="xxx.com" rt=24388.248 ua="xx.xxx.xxx.xx:8082" us="101" ut="24388.248" ul="0" cs=-

log format:

    log_format  main_ext  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for" '
                          '"$host" sn="$server_name" '
                          'rt=$request_time '
                          'ua="$upstream_addr" us="$upstream_status" '
                          'ut="$upstream_response_time" ul="$upstream_response_length" '
                          'cs=$upstream_cache_status' ;

Thanks

[chrisvdb]

I think the point he's making is that because WS connections are only logged at the end by NGINX, they often have a very long duration (minutes or hours) compared to normal web requests and hence confuse some of the Amplify graphs (min/hours vs. ms/s). I'm seeing the same thing in our setup.

[cmens]

If anyone still needs a solution for this, we solved it by filtering out http status 101 from the access.log. See the section on Conditional logging here: https://docs.nginx.com/nginx/admin-guide/monitoring/logging/

[nkashiv]

If you are still facing this problem, please create an issue in the NGINX Amplify Agent repo