Dear Bryan and HAProxy Developers,
Your insights from Sep 23 and Sep 29 helped us create an HAProxy
configuration, successfully accessing (HTTP mode) our products via HAProxy.
We incorporated all of your insights regarding:
* HTTP-request set-header (instead of reqadd path matcher)
* #dontlognull
* more useful timeout options
* maxconn
* ACL matching in port forwarded LAN environment
* rectified an error in reqrep regular expression
Thank you for your encouraging and timely help.
--
Sincerely,
Susheel Jalali
Coscend Communications Solutions_
_
Elite Premio Complex Suite 200, Pune 411045 Maharashtra India
[email protected]
Web site: www.Coscend.com
------------------------------------------------------------------
CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail
Messages from Coscend Communications Solutions' posted at:
http://www.Coscend.com/Terms_and_Conditions.html
On 10/01/15 03:12, Bryan Talbot wrote:
On Wed, Sep 30, 2015 at 1:27 PM, Susheel Jalali
<[email protected] <mailto:[email protected]>> wrote:
Dear Bryan and HAProxy Developers:
As requested, here is the complete haproxy config content.
The relevant error logs are below:
-- --
global
log 127.0.0.1 local2
log-tag haproxy
chroot /var/haproxy/lib
pidfile /var/run/haproxy.pid
user haproxy
group haproxy
nbproc 1
maxconn 256
spread-checks 5
daemon
stats socket /var/haproxy/stats
The above seems normal but maxconn=256 is pretty low but maybe that's
appropriate for your apps.
defaults
mode http
log global
option httplog
The logs you show below do not conform to this 'httplog' format and
seem to be a modified CLF, so I don't know for sure what values are in
the logs below.
option dontlognull
When debugging problems, should probably log as much as you can and
then decide what logs to hide when everything is working.
option forwardfor
option abortonclose
option http-server-close
option redispatch
retries 3
All seem normal
timeout queue 86400
timeout client 86400
timeout server 86400
timeout connect 86400
timeout http-keep-alive 30
timeout http-request 10
timeout check 20
maxconn 50000
Default time values are in milliseconds so http-request must be
completed in 10 ms. This might work fine on a LAN but will be an issue
on a WAN or internet. I'm guessing that you assumed that time units
default to seconds instead of milliseconds? If so, then these values
are still a problem but then some will be way too long -- do you
really want requests to queue and to wait to connect to a backend
server for a full day (86,400 seconds / 24 hours)?
frontend webapps-frontend
bind *:80
acl host_coscend req.hdr(Host) coscend.com:80
<http://coscend.com:80>
This will only match if the Host header value includes the port which
is uncommon especially for port :80
acl path_subdomain_p1 path_beg -i /Product1
use_backend subdomain_p1-backend if host_coscend path_subdomain_p1
default_backend webapps-backend
backend webapps-backend
[ - - -]
option http-server-close
server Product1.VM0 12.12.12.112:6012
<http://12.12.12.112:6012> cookie pad-p check
server is named "Product1.VM0" here but appears in logs below as
"Product1" which leads me to believe that this config is not used to
produce the logs.
backend subdomain_p1-backend
http-request set-header Host 12.12.12.112:6012
<http://12.12.12.112:6012>
reqirep ^([^\ :]*)\ /Product1/(.*) \1\ /\2
acl hdr_location res.hdr(Location) -m found
rspirep ^Location:\ (http?://12.12.12.112
<http://12.12.12.112>(:[0-9]+)?)?(/.*) Location:\ /Product1 if
hdr_location
server Product1.VM0 12.12.12.112:6012
<http://12.12.12.112:6012> cookie pad-p check
server is named "Product1.VM0" here but appears in logs below as
"Product1" which leads me to believe that this config is not used to
produce the logs.
admin.log
Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-frontend
started.
Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-frontend
started.
Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-backend
started.
Sep 30 12:42:29 localhost haproxy[1691]: Proxy webapps-backend
started.
Sep 30 12:42:29 localhost haproxy[1691]: Proxy
subdomain_p1-backend started.
Sep 30 12:42:29 localhost haproxy[1691]: Proxy HAProxy-stats started.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping frontend
webapps-frontend in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping frontend
webapps-frontend in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping backend
webapps-backend in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping backend
webapps-backend in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping backend
subdomain_p1-backend in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Stopping proxy
HAProxy-stats in 0 ms.
Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-frontend
stopped (FE: 4 conns, BE: 0 conns).
Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-frontend
stopped (FE: 4 conns, BE: 0 conns).
Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-backend
stopped (FE: 0 conns, BE: 1 conns).
Sep 30 12:47:29 localhost haproxy[5690]: Proxy webapps-backend
stopped (FE: 0 conns, BE: 1 conns).
Sep 30 12:47:29 localhost haproxy[5690]: Proxy
subdomain_p1-backend stopped (FE: 0 conns, BE: 1 conns).
Sep 30 12:47:29 localhost haproxy[5690]: Proxy HAProxy-stats
stopped (FE: 26 conns, BE: 12 conns).
Why are proxy frontends repeated twice in the above log but backends
(and other entries) just once? Did you produce this output with a
config different from what you provided above too?
Info.log
Conditional backend
Sep 30 12:47:29 localhost haproxy[1691]: 192.168.100.153 - - "GET
/CoscendPad HTTP/1.1" 404 262 "" "" 53639 804 "webapps-frontend"
"subdomain_p1-backend" "Product1" 5 0 0 3 8 ---- 4 4 0 0 0 0 0 "" ""
The server "Product1" was connected to (in 0 ms) and responded (in 3
ms) with a 404 status code of 262 bytes -- if my assumptions about
your modified CLF log format is correct.
Default backend:
Sep 30 12:47:29 localhost haproxy[1691]: 192.168.100.153 - - "GET
/favicon.ico HTTP/1.1" 200 4603 "" "" 53639 813 "webapps-frontend"
"webapps-backend" "Product1" 30 0 0 3 34 ---- 1 1 0 0 0 0 0 "" ""
Sincerely,
Susheel Jalali
Coscend Communications Solutions
[email protected] <mailto:[email protected]>
