HAProxy: отобразить «BADREQ» | BADREQ тысячами

Моя конфигурация HAProxy.

#HA-Proxy version 1.3.22 2009/10/14  Copyright 2000-2009 Willy Tarreau <w@1wt.eu>
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. cR (согласно документации 1.3) - это ход HTTP-запроса тайм-аута перед тем, как клиент отправит полный HTTP-запрос. Иногда это происходит из-за слишком больших значений TCP MSS на стороне клиента для сетей PPPoE, которые не могут транспортировать полноразмерные пакеты, или из-за того, что клиенты отправляют запросы вручную и не набирают достаточно быстро или забывают ввести пустую строку в конце запрос. Код состояния HTTP, скорее всего, здесь 408.

Верно на 408, но мы получаем буквально тысячи таких запросов каждый час. (Этот фрагмент журнала представляет собой клип примерно на 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>"

Из того, что я прочитал в Google, если я хотел увидеть, что такое плохие запросы, я могу показать ошибки в сокете, и он их выплюнет. У нас действительно есть веб-сайт с высокой посещаемостью, и процент «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 минут.

Ваши таймауты слишком малы. Увеличьте их.

timeout connect 30s
timeout client  30s

Абсолютный минимум - 5 секунд для трафика между двумя серверами в одной стойке. TCP-соединение открывается за 3 секунды, если есть потеря пакетов, что неизменно происходит время от времени.

Минимальный тайм-аут составляет 15 секунд для поддержки международного трафика, например, клиент из Австралии подключается к серверу в Северной Америке. В некоторых регионах мира довольно большая задержка и низкая пропускная способность, намного хуже, чем можно было бы ожидать. Разумные тайм-ауты - необходимое условие для ведения бизнеса по всему миру.

Минимальный тайм-аут составляет 30 секунд для поддержки мобильных соединений и плохого приема Wi-Fi. Это ненадежное соединение, которое может испытывать и действительно испытывает короткие периоды отключения электроэнергии.

Иметь ввиду. Таймауты предназначены для обработки наихудшего сценария подключения, и они должны обнаруживать только действительно неудачные подключения. Их можно было бы установить несколько короче, но это не дает никаких преимуществ, кроме генерирования ошибок на клиентах и серверах, что не является преимуществом.

Учтите, что периодический запрос, отправляемый каждые 5 секунд, такой простой, как проверка работоспособности или API опроса, на самом деле составляет 17280 запросов в день. Таким образом, правильная настройка тайм-аута должна вызывать менее 0,01% ложных срабатываний или создавать ошибки каждый день без причины.

88500 сеансов и 4500 ошибок за последние 20 минут.

Это 5% ошибок. Это очень высокий процент ошибок.

Учитывая, что средняя веб-страница требует для загрузки более 20 подзапросов, это означает, что каждая отдельная страница на вашем сайте не загружается частично.

попробуйте явно установить: timeout http-request 20s

Другая возможность заключается в том, что в заголовках HTTP-запроса есть недопустимые символы, и HAProxy отказывается на этом основании. Отказ может быть хорошей практикой, если это боты с плохим скриптом. Если вы хотите их разрешить, установите: option accept-invalid-http-request