On Sat, May 24, 2014 at 08:40:35AM -0400, Dan Crosta wrote: > I'm a little confused about what exactly creates a 5xx response code from > HAProxy. I think that if the backend generates a 5xx response, this will > show up as a frontend_5xx, and I expect that the value of the hrsp_5xx stat > for the frontend should equal the sum of the hrsp_5xx values from the > backends. However, this doesn't jive with what we actually see in the > statistics output: > > > $ curl -s "http://10.1.99.106:8080/haproxy?stats;csv;norefresh"; | tr "," " > " | cut -f 1,2,44 | head -n 19 > # pxname svname hrsp_5xx > myfrontend FRONTEND 10797124 > mybackend host001 24364 > mybackend host002 17260 > mybackend host003 25250 > mybackend host004 15135 > mybackend host005 17364 > mybackend host006 24541 > mybackend host007 11422 > mybackend host008 14199 > mybackend host009 13274 > mybackend host010 12797 > mybackend host011 24532 > mybackend host012 23599 > mybackend host013 31728 > mybackend host014 24607 > mybackend host015 14851 > mybackend host016 13937 > mybackend BACKEND 10797124 > > > The sum of the hrsp_5xx's for each of the individual backends is 308860, > while both the FRONTEND and BACKEND numbers are about 30 times as much. > > Am I missing something obvious? Does HAProxy ever generate 5xx responses > itself, either in the backend or frontend? Is there some more detailed > logging we should enable to track this down?
Yes it can generate 5xx when it cannot deliver the request somewhere. For example if you're running with many use_backend rules and no default_backend, it's possible that a number of requests en up going nowhere and are rejected as 503. In your case since we're seeing the same number in the frontend and in the backend and you have much less errors on the servers themselves, that can be explained by 503 when the queue is overflown (requests that are never served because of too low a server maxconn value, too short queue timeouts, or too long server response times). Hoping this helps, Willy
