Hello!
I recently ran into a case where I was hunting down the cause of the
termination of a request looking like the following (IPs changed to
protect the innocent and/or guilty):
Mar 26 23:01:43 localhost haproxy[17207]: 1.2.3.4:19036
[26/Mar/2015:23:01:43.477] http-in http-in/<NOSRV> -1/-1/-1/-1/0 503
1130 - - SC-- 601/38/0/0/0 0/0 {||3.4.5.6||||||} {||||||||||||||||}
"GET / HTTP/1.1"
What first caught my eye was the 'SC' termination state, which I
believed suggested that a backend server had rejected this request.
However as you can see from above, not only is there no backend, it is
a <NOSRV>.
After fumbling around for a bit I realized that this request matched a
'tcp-request connection reject' in the frontend. This surprised me, as
I didn't anticipate the resulting termination_state. The docs
specifically say that an 'S' means that the session was aborted "by
the server", when in fact no server was involved, as evidenced by the
<NOSRV> line.
If this is working as intended, would it be reasonable to adjust the
documentation of the flags to account for such a case?
I'm also trying to determine how to appropriately monitor these cases.
If a flag says 'S', up until now I've believed that to have only been
possibly caused by a server, and as such my monitoring is designed
with this assumption. Now I realize that if it is 'S', I guess I need
to check the server info in the log to determine if it was truly a
server's fault, or it was nuked by haproxy. Any thoughts or
suggestions?
If this is *not* working as intended, might I suggest a special
termination flag, like what we get with 'tarpit'?
Thanks!
Jason Harvey
