web-dev-qa-db-ja.com

HAProxy：「BADREQ」を表示する|何千ものBADREQ

私のHAProxy設定。

#HA-Proxy version 1.3.22 2009/10/14  Copyright 2000-2009 Willy Tarreau <[email protected]>
global
    maxconn 10000
    spread-checks 50
    user haproxy
    group haproxy
    daemon
    stats socket /tmp/haproxy
    log localhost   local0
    log localhost   local1 notice

defaults
    mode    http
    maxconn 50000
    timeout client 10000
    option forwardfor except 127.0.0.1
    option httpclose
    option httplog

listen dcaustin 0.0.0.0:80
    mode http
    timeout connect 12000
    timeout server 60000
    timeout queue 120000
    balance roundrobin
    option httpchk GET /index.html
    log global
    option httplog
    option dontlog-normal
    server web1 10.10.10.101:80 maxconn 300 check fall 1
    server web2 10.10.10.102:80 maxconn 300 check fall 1
    server web3 10.10.10.103:80 maxconn 300 check fall 1
    server web4 10.10.10.104:80 maxconn 300 check fall 1

listen stats 0.0.0.0:9000
    mode http
    balance
    log global
    timeout client 5000
    timeout connect 4000
    timeout server 30000
    stats uri /haproxy

HAProxyが実行されており、ソケットが機能しています...

adam@dcaustin:/etc/haproxy# echo "show info" | socat stdio /tmp/haproxy 
Name: HAProxy
Version: 1.3.22
Release_date: 2009/10/14
Nbproc: 1
Process_num: 1
Pid: 6320
Uptime: 0d 0h14m58s
Uptime_sec: 898
Memmax_MB: 0
Ulimit-n: 20017
Maxsock: 20017
Maxconn: 10000
Maxpipes: 0
CurrConns: 47
PipesUsed: 0
PipesFree: 0
Tasks: 51
Run_queue: 1
node: dcaustin
desiption:

エラーはソケットから何も表示しません...

adam@dcaustin:/etc/haproxy# echo "show errors" | socat stdio /tmp/haproxy 
adam@dcaustin:/etc/haproxy#

しかしながら...

エラーログがエラーコードcRの「badrequests」で爆発しています。 cR（1.3のドキュメントによる）は、クライアントが完全なHTTPリクエストを送信する前の「タイムアウトhttp-request」ストロークです。これは、フルサイズのパケットを転送できないTCPネットワークのクライアント側のPPPoE MSS値が大きすぎるか、クライアントが手動で要求を送信することによって発生することがあります。十分な速さで入力していないか、リクエストの最後に空の行を入力するのを忘れています。HTTPステータスコードは、ここでは408である可能性があります。

408で修正しましたが、文字通り1時間ごとに何千ものこれらのリクエストを受け取っています。 （このログスニペットは約10秒間のクリップです...）

Jun 30 11:08:52 localhost haproxy[6320]: 92.22.213.32:26448 [30/Jun/2011:11:08:42.384] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10002 408 212 - - cR-- 35/35/18/0/0 0/0 "<BADREQ>"
Jun 30 11:08:54 localhost haproxy[6320]: 71.62.130.24:62818 [30/Jun/2011:11:08:44.457] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10001 408 212 - - cR-- 39/39/16/0/0 0/0 "<BADREQ>"
Jun 30 11:08:55 localhost haproxy[6320]: 84.73.75.236:3589 [30/Jun/2011:11:08:45.021] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10008 408 212 - - cR-- 35/35/15/0/0 0/0 "<BADREQ>"
Jun 30 11:08:55 localhost haproxy[6320]: 69.39.20.190:49969 [30/Jun/2011:11:08:45.709] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 37/37/16/0/0 0/0 "<BADREQ>"
Jun 30 11:08:56 localhost haproxy[6320]: 2.29.0.9:58772 [30/Jun/2011:11:08:46.846] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10001 408 212 - - cR-- 43/43/22/0/0 0/0 "<BADREQ>"
Jun 30 11:08:57 localhost haproxy[6320]: 212.139.250.242:57537 [30/Jun/2011:11:08:47.568] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 42/42/21/0/0 0/0 "<BADREQ>"
Jun 30 11:08:58 localhost haproxy[6320]: 74.79.195.75:55046 [30/Jun/2011:11:08:48.559] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 46/46/24/0/0 0/0 "<BADREQ>"
Jun 30 11:08:58 localhost haproxy[6320]: 74.79.195.75:55044 [30/Jun/2011:11:08:48.554] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10004 408 212 - - cR-- 45/45/24/0/0 0/0 "<BADREQ>"
Jun 30 11:08:58 localhost haproxy[6320]: 74.79.195.75:55045 [30/Jun/2011:11:08:48.554] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10005 408 212 - - cR-- 44/44/24/0/0 0/0 "<BADREQ>"
Jun 30 11:09:00 localhost haproxy[6320]: 68.197.56.2:52781 [30/Jun/2011:11:08:50.975] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 49/49/28/0/0 0/0 "<BADREQ>"

私がグーグルで読んだものから、悪いリクエストが何であるかを見たい場合は、ソケットにエラーを表示することができ、それはそれらを吐き出します。私たちはかなりトラフィックの多いWebサイトを運営しており、通常のリクエストに対する「BADREQS」の割合は非常に低いですが、デバッグできるように、そのリクエストが何であったかを把握できるようにしたいと思います。

統計

# pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max,
dcaustin,FRONTEND,,,64,120,50000,88433,105889100,2553809875,0,0,4641,,,,,OPEN,,,,,,,,,1,1,0,,,,0,45,0,128,
dcaustin,web1,0,0,10,28,300,20941,25402112,633143416,,0,,0,3,0,0,UP,1,1,0,0,0,2208,0,,1,1,1,,20941,,2,11,,30,
dcaustin,web2,0,0,9,30,300,20941,25026691,641475169,,0,,0,3,0,0,UP,1,1,0,0,0,2208,0,,1,1,2,,20941,,2,11,,30,
dcaustin,web3,0,0,10,27,300,20940,30116527,635015040,,0,,0,9,0,0,UP,1,1,0,0,0,2208,0,,1,1,3,,20940,,2,10,,31,
dcaustin,web4,0,0,5,28,300,20940,25343770,643209546,,0,,0,8,0,0,UP,1,1,0,0,0,2208,0,,1,1,4,,20940,,2,11,,31,
dcaustin,BACKEND,0,0,34,95,50000,83762,105889100,2553809875,0,0,,0,34,0,0,UP,4,4,0,,0,2208,0,,1,1,0,,83762,,1,43,,122,

88500「セッション」と4500エラー。過去20分間で。

load-balancingubuntu-10.04reverse-proxyhaproxy
6
grufftech

タイムアウトが短すぎます。それらを増やします。

timeout connect 30s
timeout client  30s

同じラック内の2つのサーバー間のトラフィックの絶対最小値は5秒です。 A TCPパケット損失がある場合、接続が開くまでに3秒かかります。これは、常に発生することがあります。

オーストラリアからのクライアントが北米のサーバーに接続する場合のように、国際トラフィックをサポートするための最小タイムアウトは15秒です。世界の一部の場所では、予想よりもはるかに悪い遅延と低帯域幅があります。タイムアウトを合理的にすることは、世界中でビジネスを行うための前提条件です。

モバイル接続と不十分な受信WiFiをサポートするための最小タイムアウトは30秒です。短期間の停電が発生する可能性があり、実際に発生するのは信頼性の低い接続です。

覚えておいてください。タイムアウトは、接続の最悪のシナリオを処理するためのものであり、本当に失敗した接続のみをキャッチする必要があります。それらはいくらか短く設定できますが、これはクライアントとサーバーでエラーを生成することを除いて利点がありません。これは利点ではありません。

ヘルスチェックやポーリングAPIのような単純な、5秒ごとに行われる定期的なリクエストは、実際には1日あたり17280件ものリクエストであると考えてください。したがって、適切なタイムアウト設定では、誤検知の0.01％未満が発生するか、理由もなく毎日エラーが発生します。

過去20分間に88500セッションと4500エラー。

これはエラーの5％です。これは非常に高いエラー率です。

平均的なウェブページの読み込みに20を超えるサブリクエストが必要であることを考えると、サイトのすべてのページが部分的に読み込まれないことを意味します。

1
user5994461

明示的に設定してみてください：timeout http-request 20s

もう1つの可能性は、httpリクエストヘッダーに無効な文字があり、HAProxyがそれに基づいて拒否していることです。スクリプトが不十分なボットの場合、拒否することは良いことかもしれません。それらを許可する場合は、次のように設定します。option accept-invalid-http-request

0
ERR0