haproxy的tcplog或httplog提供了乙個"termination_state"字段，這個字段提供了乙個session是如何中斷的指示器。在tcplog中是2個字元，在httplog中是4個字元， 通常我們初步定位故障是用前兩個字元。
該含義表示什麼事件導致了session中斷:
該字元表示當session被關閉時，該session當時所處的狀態:
haproxy的log記錄了每個request的相關資訊，典型的http log格式如下:
2019-07-06 15:48:12.503 localhost haproxy [pid:29670]info 30.8.3.100:49858 [06/jul/2019:15:48:10.953] karbor_8799~ b_def_karbor_8799/controller1 34/0/95/1420/1550 200 473 - - ---- 5/5/5/5/0 0/0 "get /v1/9b47d36a3ee44b42b45caf70b90f82f4/protection_capabilities http/1.1"日誌如下：
nov 26 07:08:16 localhost haproxy[20695]: 127.0.0.1:39508 [26/nov/2015:07:08:16.154] http http/ -1/-1/-1/-1/410 400 187 - - pr-- 0/0/0/0/0 0/0 ""(-1/-1/-1/-1/410)這幾個timer的數值揭示了可能的原因。數值"-1"說明了request沒有到達相應的階段就被終止了。第乙個"-1"說明http request header還沒有被完全接收完畢之前，連線就斷掉了。另外""可以看到這個連線沒有被任何backend伺服器處理。
日誌如下：
注意7476這個數值，即7476ms，超過了7s的時間。這表明上層proxy和haproxy之間網路連線可能有問題。通常來說http頭非常小，正常情況下乙個tcp包就可以容納，接收乙個http header不可能需要這麼久。
例如：10/0/30/69/109這些數字就是haproxy內部的timer,單位是ms，以下是依次詳細說明:
當log中的tr的值很高的時候，通常意味著問題出在了server這一邊。為了進一步排查問題，在haproxy上已經不行了，需要到server伺服器上去查詢原因。如果server響應非常慢，那麼可能你會看到佇列計數器的值也跟著增加了。
例如：1/1/1/1/0這個數值是當時佇列狀態的快照，以下是依次詳細說明:
有時候我們可以需要通過在haproxy的日誌中增加header的列印，來定位問題，具體操作如下：在frontend的配置中增加：
...比如我在http的request的headers中增加了時間戳，在haproxy中則可以通過設定獲取到
haproxy日誌配置
aproxy配置日誌策略 預設情況下,haproxy是沒有配置日誌的 在centos6.3下預設管理日誌的是rsyslog,可以實現udp日誌的接收,將日誌寫入檔案,寫入資料庫 先檢測rsyslog是否安裝 rpm q rsyslog 安後在 etc rsyslog.d 下建立haproxy.con...
Haproxy日誌管理
haproxy在使用過程中，配置完成後日誌無法正常輸出，centos6 的配置過程 setenforce 0 關閉selinux vim etc rsyslog.conf 在檔案左後加入下面兩行 haproxy local0.usr local haproxy logs haproxy.log 指定...
haproxy引數解析
haproxy工作於隧道模式，其僅檢查每乙個連線的第乙個請求，1.option abortonclose 當伺服器負載過高時，將自動關閉佇列中處理時間較長的連線請求 每次請求完畢後，關閉http通道 使用該引數，每處理完乙個request時，haproxy都會去檢查http頭中的connection...