Hi all,
I've just upgraded some hosts to 1.6.4 (from 1.5) and immediately got a
bunch of SMS because we're using stick-tables to track the connections
and monitor http_req_rate. The stick-tables data will be synced to the
other peers using the "peers" section.
So I setup a test case using two HAProxy instances with e.g.:
global
user haproxy
group haproxy
maxconn 10000
stats socket /var/run/haproxy.stat user haproxy gid haproxy mode
600 level admin
# aus der anti-dos config
defaults
timeout client 60s
timeout server 60s
timeout queue 60s
timeout connect 3s
timeout http-request 10s
frontend test
bind 0.0.0.0:8080
mode http
tcp-request inspect-delay 7s
tcp-request content track-sc1 src table backend_sourceip
tcp-request content reject if {
sc1_http_req_rate(backend_sourceip) gt 15 }
http-request deny if { sc1_http_req_rate(backend_sourceip) gt 15
}
peers foo_peers
peer host1 172.16.0.128:8024
peer host2 172.16.0.16:8024
backend backend_sourceip
# 1mio IPs, 8hrs TTL per entry for several stats per IP in 10s
stick-table type ip size 1m expire 8h store
gpc0,conn_cnt,conn_cur,conn_rate(10s),http_req_cnt,http_req_rate(10s),http_err_cnt,http_err_rate(10s)
peers foo_peers
I then have 4 terminals, two for doing a:
watch "echo 'show table backend_sourceip' | socat stdio
/var/run/haproxy.stat"
and two for doing some "curl -Lvs http://127.0.0.1:8080" by hand.
If you do some on the first and some on the second host you'll notice
different values on one side. Also the counter may e.g. double while the
other side has the correct/actual value. This results into several
thousands of requests on our prod. systems but according to the logs it
can't be correct.
Does anybody else have similar weirdness or can you guys confirm false
values?
The *_cnt values seem to be ok but the *_rate ones seem to be false in
some cases.
--
Regards,
Christian Ruppert
I've just upgraded some hosts to 1.6.4 (from 1.5) and immediately got a
bunch of SMS because we're using stick-tables to track the connections
and monitor http_req_rate. The stick-tables data will be synced to the
other peers using the "peers" section.
So I setup a test case using two HAProxy instances with e.g.:
global
user haproxy
group haproxy
maxconn 10000
stats socket /var/run/haproxy.stat user haproxy gid haproxy mode
600 level admin
# aus der anti-dos config
defaults
timeout client 60s
timeout server 60s
timeout queue 60s
timeout connect 3s
timeout http-request 10s
frontend test
bind 0.0.0.0:8080
mode http
tcp-request inspect-delay 7s
tcp-request content track-sc1 src table backend_sourceip
tcp-request content reject if {
sc1_http_req_rate(backend_sourceip) gt 15 }
http-request deny if { sc1_http_req_rate(backend_sourceip) gt 15
}
peers foo_peers
peer host1 172.16.0.128:8024
peer host2 172.16.0.16:8024
backend backend_sourceip
# 1mio IPs, 8hrs TTL per entry for several stats per IP in 10s
stick-table type ip size 1m expire 8h store
gpc0,conn_cnt,conn_cur,conn_rate(10s),http_req_cnt,http_req_rate(10s),http_err_cnt,http_err_rate(10s)
peers foo_peers
I then have 4 terminals, two for doing a:
watch "echo 'show table backend_sourceip' | socat stdio
/var/run/haproxy.stat"
and two for doing some "curl -Lvs http://127.0.0.1:8080" by hand.
If you do some on the first and some on the second host you'll notice
different values on one side. Also the counter may e.g. double while the
other side has the correct/actual value. This results into several
thousands of requests on our prod. systems but according to the logs it
can't be correct.
Does anybody else have similar weirdness or can you guys confirm false
values?
The *_cnt values seem to be ok but the *_rate ones seem to be false in
some cases.
--
Regards,
Christian Ruppert