当haproxy部署在复杂网络环境下时，一旦出现问题，我们需要log来帮助我们分析定位故障。haproxy的log提供了非常详尽的信息，本文作为读文档的笔迹，会边读边改，希望最后能形成一份有用的东西。
一、hparoxy日志中的termination_state
haproxy的tcplog或httplog提供了一个"termination_state"字段，这个字段提供了一个session是如何中断的指示器。在tcplog中是2个字符，在httplog中是4个字符，
通常我们初步定位故障是用前两个字符。
- 第一个字符的含义，是什么事件导致了session中断:
C : TCP session 由于client原因意外终止.
S : TCP session
由于server原因意外终止，或者被server明确拒绝.
P : session过早的被proxy终止。原因可以是实施了connection
limit，或者被匹配了一个DENY acl，或者由于server回应的信息中带有某些危险的错误，没有通过安全检查，而被阻止(例如:
可缓存的cookie)
L :
session被haproxy本地处理，没有传递给后端server。这个标志通常发生在stats和redirect操作.
R : proxy上的某个资源已经耗尽(内存, socket, 源端口...).
通常这个标志出现在connection阶段，系统日志内也会包含一个同样的错误信息，如果出现了这样的错误，那么必须尽快处理。
I :
proxy自检出现内部错误。这个错误应该永远不会出现，如果你在log中发现这个错误，那么通常是haproxy出现了bug。通常的解决方法是冷重启haproxy。
D : session被haproxy关闭，因为后端server被检测到宕机。
U : session被haproxy关闭，当后端server
failback的时候关闭backup server的连接.
K : session被haproxy的管理操作主动关闭.
c : client-side timeout，等待client收发数据超时.
s : server-side timeout，等待server手法数据超时.
- : session正常结束.
-
第二个字符的含义，当session被关闭时，该session当时所处的状态:
R : proxy正等待连接完成，等待client的合法的REQUEST.
此时尚未向任何server发送过数据.(仅用于HTTP mode)
H : proxy正等待连接完成，等待server的合法respone
HEADERS.(仅用于HTTP mode)
Q :
proxy正在队列中等待进行连接。这个标志当server设置了'maxconn'参数会出现.当持续试图redispatch请求到一个垂死的server的时候，也有可能出现在全局queue中。
如果没有redispatch发生，则不会与任何server试图建立连接.
C : proxy正等待与server建立连接.
D : session处于DATA阶段.
L :
proxy正在向client传送最后的data，此时server已经完成传送。这个状态很罕见，只会发生在client在接收最后的数据包时突然死掉。
T : requset被故意延迟了，连接在整个"timeout
tarpit"期间一直保持打开或者直到client关闭，两者都会被计入"Tw"计时器项目中.
- : session正常结束.
参考文档:
https://deviantony.wordpress.com/2014/10/30/rabbitmq-and-haproxy-a-timeout-issue/
http://agiletesting.blogspot.hk/2014/07/troubleshooting-haproxy-502-errors.html
https://www.digitalocean.com/community/tutorials/how-to-implement-ssl-termination-with-haproxy-on-ubuntu-14-04
http://www.adheaven.com/post/22208788775/solving-problem-with-502-bad-gateway-in-haproxy
http://www.steviecaldwell.com/2014/09/troubleshooting-haproxy.html
