Hi Andreas,
On Thu, Jun 09, 2011 at 03:55:46PM +0200, Andreas wrote:
Hi,
we are using haproxy only in tcp mode.
Actually we have the problem that we see broken requests on our backend
server, but we cannot see which client group is causing the problem.
That's because we only see the IP and the source port of haproxy in our
server logs and the client IP and source port in the haproxy log.
It would be cool to have the local source port of haproxy logged so that
we can find the corresponding logfile entry from the haproxy logs.
I know what you're talking about, it happened to me to have the same issue
too. While I don't want to touch the HTTP log format until we can make it
totally flexible, I think that extending the TCP one is not a big deal.
We should have a backend option log-outgoing-address which when enabled
would perform the getsockname() on the server-side socket and add that in
the logs. It would tremendously help making the relation between both sides.
If you want to work on such a thing, I'm willing to merge it into 1.5.
Or does somebody have a better idea to find out the right connections?
If you don't have too many new connections per second and if your servers
are NTP-synchronized, you can use the connection accept date which should
be the same on the server modulo 1 ms.
Alternatives involve working in transparent mode or implementing the PROXY
protocol in your servers and enabling it on haproxy. It will then pass all
the info there.
If your issue happens often enough and the load is not too high (less than
about 10% CPU), then you can run strace on haproxy (strace -tto log -p PID).
I'm often doing that to guess what FD is associated to what other FD, because
you can see contents and precise timing which let you match a connect() with
an accept(). It's not always usable but sometimes quite handy. Sometimes you
have to combine it with tcpdump running on the same system if you absolutely
need the source port of the outgoing connection.
Hoping this helps,
Willy
