Nginx 访问日志条目在发生时不会为某些连接创建 [英] Nginx access logs entries don't get created for some connections when they happen

查看:56
本文介绍了Nginx 访问日志条目在发生时不会为某些连接创建的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的网站架构如下:

internet --> loadbalancer --> webserver/api

internet --> loadbalancer --> webserver/api

因此,负载均衡器机器上有一个 nginx 设置为负载均衡器,并且 webserver/api 节点上也有一个 nginx 充当反向代理.Web 服务器服务器接收来自浏览器的请求(通过负载均衡器),通过 HTTP 访问 api 并将页面呈现给浏览器.webserver 和 api 都是 nodejs 应用.

So there is an nginx on the load balancer machine setup as a load balancer and there is also an nginx on the webserver/api node functioning as a reverse proxy. The webserver server receives requests from browsers (via the load balancer), accesses the api over HTTP and renders the page to the browser. The webserver and api are both nodejs apps.

nginx 负载平衡器有 webserver-->api 连接的日志条目,但它不会记录初始客户端浏览器-->webserver 连接,直到浏览器关闭(用 Chrome 和 Firefox 测试).就好像连接一直处于未完成状态,直到浏览器完全关闭,此时才会写入日志条目.

The nginx load balancer has log entries for the webserver-->api connections, but it doesn't log the initial client browser-->webserver connections until the browser is closed (tested with Chrome and Firefox). It's as though the connection is kept in an unfinished state until the browser is fully shutdown, at which point the log entry is written.

nginx 负载均衡器访问日志:

nginx load balancer access logs:

110.110.110.101 - - [21/Feb/2019:22:21:23 +0000] loadbalancer01 TCP 200 186833 825 0.047 upstream: 10.0.0.100:443
110.110.110.100 - - [21/Feb/2019:22:21:37 +0000] loadbalancer01 TCP 200 24327 3856 21.991 upstream: 10.0.0.100:443 <-- only created after browser is closed

  • 110.110.110.100 - 与 Chrome/Firefox 连接的客户端 IP
  • 110.110.110.101 - webserver/api 节点公共接口
  • 10.0.0.100 - webserver/api 节点私有接口
  • webserver->api 连接首先被记录,即使它显然是第二个,并且客户端浏览器->webserver 连接仅在客户端浏览器完全关闭时被记录.

    The webserver->api connection is logged first even though it clearly happens second, and the client browser->webserver connection only gets logged when the client browser is completely closed.

    是否有某种缓冲发生?我没有在流块日志记录配置中使用 buffer 参数:

    Is there some sort of buffering happening? I'm not using the buffer parameter in the stream block logging configuration:

    log_format combined '$remote_addr - - [$time_local] $hostname $protocol $status $bytes_sent $bytes_received $session_time upstream: $upstream_addr';
    
    access_log /var/log/nginx/access.log combined;
    

    为什么只有在浏览器关闭时才会记录连接?如何确保在连接发生时记录初始连接?

    Why does the connection only get logged when the browser is closed? How can I ensure that the initial connection is logged when the connection happens?

    [更新 - 添加日志配置,同时注意ips已被编辑]

    [update - added log configuration, also note that ips have been redacted]

    推荐答案

    我通过比较浏览器与负载均衡器连接之间的标头与从脚本启动的连接之间的标头,发现了这一点.结果浏览器设置了Connection: keep-alive"标头,它保持连接打开如此多可以使用相同的连接发送请求.

    I figured this out by comparing the headers between a browser connection to the load balancer compared to a connection initiated from a script. Turns out the browsers set "Connection: keep-alive" header which keeps the connection open so multiple requests can be sent using the same connection.

    在负载均衡器公共 ip 上运行此命令以查看连接标头的有用命令:

    Useful commands to run this on the load balancer public ip to see the connection headers:

    sudo tcpdump -nn -A -s1500 -l -i eth0 端口 80

    sudo tcpdump -nn -A -s1500 -l -i eth0 port 80

    另一件需要注意的事情是,如果您使用 ufw 作为防火墙,它会设置底层 iptables 规则并带有限制,因此它每分钟只记录前 3 个连接.

    The other thing to note is that if you are using ufw as firewall, it sets up the underlying iptables rules with limits so it only logs the 1st 3 connections per min.

    这篇关于Nginx 访问日志条目在发生时不会为某些连接创建的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆