haproxy provides 5 log formats, there aredefault log、tcplog、HTTPlog、CLFHTTPlog、custom log
default log
haproxy's default log format
Nov 26 05:56:17 localhost haproxy[3521]: Connect from 11.2.2.66:51659 to 11.2.3.25:80 (web/HTTP)
| format | Log field |
|---|---|
| process_name ‘[’ pid ‘]:’ | haproxy[3521]: |
| ‘Connect from’ | Connect from |
| source_ip ‘:’ source_port | 11.2.2.66:51659 |
| ‘to’ | to |
| ‘(’ frontend_name ‘/’ mode ‘)’ | (www/HTTP) |
tcplog
tcplog is the recommended format for pure tcp agents, and it is quite helpful for providing troubleshooting information. Due to the counter and the number of bytes, it is always sent after the end of the session. If used option logasap, it can be issued earlier. Most are suitable for long conversations. It is option dontlognullalso possible to specify on the front end not to send logs for sessions that do not exchange data between the client and the server. If specified on the front end option donlog-normal, successful connections will not be recorded.
Log format:
Nov 26 06:51:26 localhost haproxy[6308]: 11.2.3.25:60042 [26/Nov/2020:06:51:24.395] mysql sqlserver/sql1 1/0/1710 188 -- 0/0/0/0/0 0/0
| format | Log field |
|---|---|
| process_name ‘[’ pid ‘]:’ | haproxy[3521]: |
| source_ip ‘:’ source_port | 11.2.3.25:60042 |
| ‘[’ accept_date ‘]’ | [26/Nov/2020:06:51:24.395] |
| frontend_name | mysql |
| backend_name ‘/’ server_name | sqlserver/sql1 |
| Tw ‘/’ Tc ‘/’ Tt* | 1/0/1710 |
| bytes_read* | 188 |
| termination_state | – |
| actconn ‘/’ feconn ‘/’ beconn ‘/’ srv_conn ‘/’ retries* | 0/0/0/0/0 |
| srv_queue ‘/’ backend_queue | 0/0 |
Tw: The time spent in various queues, the default is millisecondsTc: The total time waiting for the connection, from the client to the final connection with the server, including retryTt: It contains the length of time from receiving to the last processing. The length of this period comes from the possible processing time of the server. If usedoption logasap, it can be issued earlierbytes_read*: The total number of log bytes sent from the server to the client. If specifiedoption logasap, this value will be prefixed with a + sign, indicating that the last value may be greatertermination_state: Indicates in which state the session was disconnectedactconn: The number of concurrent connections on the process while recording the sessionfeconn: "Feconn" is the total number of concurrent connections on the front end when recording the session. It is useful to evaluate the amount of resources required to maintain a high load, and to detect when the frontend's "maxconn" is reached. The most common situation is that when this value rises sharply, it is because of congestion in the back-end server, but sometimes it may also be caused by a denial of service attack.beconn: Is the total number of concurrent connections on the backend while recording the sessionsrv_conn: "Srv_conn" is the total number of concurrent connections that were still active on the server when the session was recorded. It can never exceed the "maxconn" parameter of the server configuration. If this value is often close to or equal to the server's "maxconn", it means that traffic management involves a lot, meaning that the server's maxconn value is too low, or there are not enough servers to handle the load with the best response time. When the server's "srv_conn" is only one high, it usually means that the server has some problems, resulting in longer connection processing time than other servers.retries*:number of retriessrv_queque: "Srv_queue" is the total number of requests processed before this request in the server queue. It is zero when the request does not pass through the server queue. By dividing the time spent in the queue by the number of requests in the queue, the server's response time can be estimated. It is worth noting that if the session experience is dispatched and passed through two server queues, their positions will be accumulated. Unless redispatch occurs, the request should not pass through the server queue and the backend queue at the same time.backend_queque: Backend server queue
HTTP log format
The HTTP format log is most suitable for http proxy mode. Like tcp, it provides very useful help
Nov 26 07:54:47 localhost haproxy[7202]: 11.2.3.25:38168 [26/Nov/2020:07:54:47.724] web websrv/srv2 0/0/0/1/1 200 256 - - ---- 1/1/0/1/0 0/0 "GET / HTTP/1.1"
| format | Log field |
|---|---|
| process_name ‘[’ pid ‘]:’ | haproxy[7202]: |
| client_ip ‘:’ client_port | 11.2.3.25:38168 |
| ‘[’ accept_date ‘]’ | [26/Nov/2020:07:54:47.724] |
| frontend_name | web |
| backend_name ‘/’ server_name | websrv/srv2 |
| Tq '/' Tw '/' Tc '/' Tr '/' Tt * | 0/0/0/1/1 |
| status_code | 200 |
| bytes_read* | 256 |
| captured_request_cookie | - |
| captured_response_cookie | - |
| actconn ‘/’ feconn ‘/’ beconn ‘/’ srv_conn ‘/’ retries* | 1/1/0/1/0 |
| srv_queue ‘/’ backend_queue | 0/0 |
| ‘"’ http_request ‘"’ | “GET /index.html HTTP/1.1” |
Tq: It is the time consumed by sending a complete http request between the client and the server, in milliseconds. If there are a large number of requests, it is generally a network problem. Connection failure is -1web websrvs/<NOSRV> 178/-1/-1/-1/178 "Tw: The length of time waiting in the queueTc: The length of time the client connects to the final server, including the number of retriesTr: The time it takes to wait for the server to send a complete http response, not counting data. It usually matches the time the server takes to process the request. A large amount of time for a "GET" request usually indicates that the server is overloadedTt: The time elapsed from the connection to the last closing. It covers all possible processingstatus_code: Response codebytes_read*: The total number of bytes sent to the client, including the http header.
Some options can be added to the log in http mode.
capture cookie <name> len <length>: Capture a cookie in the request and response and recorded in the log, can only be used frontendand listenthe
Example:
frontend web
bind :80
default_backend websrvs
option httplog
log global
capture cookie RS len 32
backend websrvs
balance roundrobin
hash-type consistent
cookie RS indirect insert nocache
option forwardfor except 127.0.0.1 header X-RealIP-For
server web 172.17.0.2:80 cookie web check
server web1 172.17.0.3:80 check
Log performance:
Nov 26 22:39:58 localhost haproxy[17723]: 192.168.199.111:53144 [26/Nov/2020:22:39:58.077] web websrvs/web 165/0/0/1/166 304 152 RS=web - --VN 1/1/0/1/0 0/0 "GET / HTTP/1.1"
capture request header <name> len <length>: Capture the last occurrence of the specified request header information
Example:
frotend下
capture request header HOST len 15
Log display
Nov 26 23:19:57 localhost haproxy[18352]: 192.168.199.111:55897 [26/Nov/2020:23:19:57.213] web websrvs/web1 456/0/0/1/457 200 282 RS=web - ---- 2/2/0/0/0 0/0 {
192.168.199.155} "GET / HTTP/1.1"
capture response header <name> len <length>: Capture the last occurrence of the specified response header information
Example:
frontend下
capture response header Server len 40
The log shows:
Nov 26 23:23:50 localhost haproxy[18410]: 192.168.199.111:56117 [26/Nov/2020:23:23:50.430] web websrvs/web 312/0/0/1/313 200 283 RS=web - ---- 2/2/0/1/0 0/0 {
192.168.199.155} {
Apache/2.4.6 (CentOS) PHP/5.4.16} "GET / HTTP/1.1"
custom log
haproxy can define logs according to their needs
See the documentation for each parameter
Example:
capture cookie RS len 32
capture request header Cookie len 15
capture response header Server len 40
capture request header User-Agent len 30
log-format %ci:%cp\ %si:%sp\ %B\ %U\ %ST\ %r\ %b\ %f\ %bi\ %hrl\ %hsl\
%hrl: The request message information captured by capture will be displayed in CLF mode.
%hsl: The response message information captured by capture will be displayed in CLF mode.
The log shows:
Nov 27 00:13:38 localhost haproxy[19180]: 192.168.199.111:59180 172.17.0.2:80 283 560 200 GET / HTTP/1.1 websrvs web 172.17.0.1 RS=web Mozilla/5.0 (Windows NT 10.0; Apache/2.4.6 (CentOS) PHP/5.4.16\