web-dev-qa-db-ja.com

HAProxyがすべてのリクエストをログに記録しない

Ubuntu14.04とApache2でも別のバックエンドサーバーを実行しているUbuntu14.04でHAProxyをセットアップしました。

リクエストを実行するときに、それらのリクエストのすべてがログに記録されるわけではありません。 HAProxyをデバッグモードで実行している場合でも、端末にすべてのリクエストが表示されるわけではありません。

画像を含むindex.htmlがあります。 GoogleでページをリクエストするとChromeインスペクターで、合計3つのファイル（index.html、header.gif、favicon.ico）がリクエストされていることがわかります。

ただし、HAProxyはindex.htmlの実際のリクエストのみをログに記録し、ページを非常に高速にリロードすると、index.htmlのすべてのリクエストもログに記録されません。

Socatを使用してデバッグを試みましたが、その方法でログに記録されたエラーはありませんでした。ログ形式をtcplogに設定しようとしましたが、それも役に立ちませんでした。すべてのリクエストがログに記録されるわけではありませんでした。

私は何が間違っているのですか？

rsyslogd構成：

 $ ModLoad imudp 
 $ UDPServerAddress 127.0.0.1 
 $ UDPServerRun 514 
 
 local0。*-/ var/log/haproxy/haproxy.log 
 
＆〜

HAProxy構成：

 global 
 log 127.0.0.1 local0 
 log-send-hostname 
 daemon 
 maxconn 256 
 stats socket/tmp/haproxy 
 
 defaults 
 log global 
 timeout connect 5000ms 
 timeout client 50000ms 
 timeout server 50000ms 
 
フロントエンドhttp-in 
モードhttp 
オプションhttplog 
＃すべてのIPのポートにバインド9200 
 bind0.0.0.0:80
default_backendhttp -out 
 
バックエンドhttp-out 
モードhttp 
バランス最小接続
サーバーweb2xxx.xxx.xxx.xxx：80

haproxyログ

 9月17日14：38：16front2.xxx.net haproxy [5436]：xxx.xxx.xxx.xxx：61745 [17/Sep/2015：14：38：06.771] http-in http-in/-1/-1/-1/-1/10000 400187 --- CR-- 2/2/0/0/0 0/0 "" 
 9月17日14：38：16front2.xxx .net haproxy [5436]：xxx.xxx.xxx.xxx：61744 [17/Sep/2015：14：38：06.771] http-in http-out/web2 0/0/1/2/10001 200 23198 --- ---- 1/1/0/0/0 0/0 "GET /index.html HTTP/1.1" 
 9月17日14：38：26front2.xxx.net haproxy [5436]：xxx。 xxx.xxx.xxx:61746 [17/Sep/2015：14：38：06.772] http-in http-in/-1/-1/-1/-1/20000 400187 --- CR-- 0/0/0/0/0 0/0 ""

Apache2ログ

 registered.xxx.net:80 185.92.61.11 --- [17/Sep/2015：14：38：06 +0200] "GET /index.html HTTP/1.1" 200 1192 "-" "Mozilla/5.0（Windows NT 10.0; WOW64）AppleWebKit/537.36（KHTML、Geckoなど）Chrome/45.0.2454.93 Safari/537.36 "
 registered.xxx.net:80 185.92.61.11 --- [2015年9月17日： 14:38:06 +0200] "GET /header.gif HTTP/1.1" 200 4145 "http://xxx.xxx.xxx.xxx/index.html" "Mozilla/5.0（Windows NT 10.0; WOW64）AppleWebKit/537.36（KHTML、Geckoなど）Chrome/45.0.2454.93 Safari/537.36 "
 registered.xxx.net:80 185.92.61.11 --- [17/Sep/2015：14：38：06 +0200]" GET /favicon.ico HTTP/1.1 "200 17861" http://xxx.xxx.xxx.xxx/index.html "" Mozilla/5.0（Windows NT 10.0; WOW64）AppleWebKit/537.36（KHTML、Geckoなど）Chrome/45.0 .2454.93 Safari/537.36 "
logginghaproxy
2
John Plusje

1.5-dev22より前のすべてのHAProxyバージョンでは、mode httpで使用すると、他の「サブモード」が指定されていない場合、tunnel「サブモード」で機能しました。 HAProxyには実際には「サブモード」のようなものはないことはわかっていますが、他に何と呼ぶべきかわかりません。 docs Wordの「モード」を使用するだけですが、さらに混乱します...

いずれにせよ、tunnel "sub-mode"では、最初の要求と応答のみが処理され、それ以外はすべて分析なしで転送されます。このモードは、ロギングとHTTP処理で多くの問題を引き起こすため、使用しないでください。

1.5-dev22の時点で、デフォルトの「サブモード」がtunnelからkeep aliveに変更されました。これは、すべての要求と応答が処理され、接続が維持されることを意味します。開いているが、応答と新しい要求の間はアイドル状態です。

これは、フロントエンドとバックエンドでoption http-keep-alive、option http-tunnel、option httpclose、option http-server-close、およびoption forcecloseキーワードを使用して、有効モード（または「sub -mode」）ドキュメントで概説されています。セクション4の下に、特定の接続に使用されるフロントエンドとバックで設定されるオプションに基づいた効果的な「サブモード」を示す表があります。

完全を期すために、この記事の執筆時点（1.5.14）に存在する、表とさまざまな「サブモード」を含む、ドキュメントの関連セクションを次に示します。

In HTTP mode, the processing applied to requests and responses flowing over
a connection depends in the combination of the frontend's HTTP options and
the backend's. HAProxy supports 5 connection modes :

  - KAL : keep alive ("option http-keep-alive") which is the default mode : all
    requests and responses are processed, and connections remain open but idle
    between responses and new requests.

  - TUN: tunnel ("option http-tunnel") : this was the default mode for versions
    1.0 to 1.5-dev21 : only the first request and response are processed, and
    everything else is forwarded with no analysis at all. This mode should not
    be used as it creates lots of trouble with logging and HTTP processing.

  - PCL: passive close ("option httpclose") : exactly the same as tunnel mode,
    but with "Connection: close" appended in both directions to try to make
    both ends close after the first request/response exchange.

  - SCL: server close ("option http-server-close") : the server-facing
    connection is closed after the end of the response is received, but the
    client-facing connection remains open.

  - FCL: forced close ("option forceclose") : the connection is actively closed
    after the end of the response.

The effective mode that will be applied to a connection passing through a
frontend and a backend can be determined by both proxy modes according to the
following matrix, but in short, the modes are symmetric, keep-alive is the
weakest option and force close is the strongest.

                          Backend mode

                | KAL | TUN | PCL | SCL | FCL
            ----+-----+-----+-----+-----+----
            KAL | KAL | TUN | PCL | SCL | FCL
            ----+-----+-----+-----+-----+----
            TUN | TUN | TUN | PCL | SCL | FCL
 Frontend   ----+-----+-----+-----+-----+----
   mode     PCL | PCL | PCL | PCL | FCL | FCL
            ----+-----+-----+-----+-----+----
            SCL | SCL | SCL | FCL | SCL | FCL
            ----+-----+-----+-----+-----+----
            FCL | FCL | FCL | FCL | FCL | FCL
1
GregL