Thanks Pavlos for your help. Fortunately (and embarrassedly for me) the mistake was not anywhere near haproxy but instead my haproxy configure template system had a bug which mixed up the backend name and ip address. Because of this haproxy showed different names for those servers which were actually down and that threw me into way off when I investigated this issue, blinded by the actual problem which was always so near of my sight. :(
haproxy shows the server name in the server log when it reports health check statuses. Example: "Health check for server comet/comet-172.16.4.209:3500 succeeded, reason: Layer7 check passed, code: 200, info: "OK", check duration: 2ms, status: 3/3 UP." This could be improved by also showing the actual ip and port in the log. Suggestion: "Health check for server comet/comet-172.16.4.209:3500 (172.16.4.209:3500) succeeded, reason: Layer7 check passed, code: 200, info: "OK", check duration: 2ms, status: 3/3 UP." > As a side question: The documentation was a bit unclear. If I have > > nbproc > 1 and I use the admin socket to turn servers administrative > > status down or up, do I need to do it to separated admin sockets per > > haproxy process, or can I just use one admin socket? > > > > You need a different socket. Each process can only be managed by a > dedicated stats socket. There isn't any kind of aggregation where you > issue a command to 1 stats socket and this command is pushed to all > processes. Next release will address this kind of issues. > Thank you, good to know! - Garo
