Toggle navigation
主页
工具
归档
标签
HAproxy
0
无
2020-09-02 12:02:33
1
0
myron
配置日志： 1、安装 rsyslog [root@h101 ~]# rpm -qa | grep rsyslog rsyslog-5.8.10-8.el6.x86_64 2、配置rsyslog [root@h101 ~]# grep -v "^#" /etc/rsyslog.conf | grep -v "^$" $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imklog # provides kernel logging support (previously done by rklogd) $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $IncludeConfig /etc/rsyslog.d/*.conf *.info;mail.none;authpriv.none;cron.none /var/log/messages authpriv.* /var/log/secure mail.* -/var/log/maillog cron.* /var/log/cron *.emerg * uucp,news.crit /var/log/spooler local7.* /var/log/boot.log $template SpiceTmpl,"%TIMESTAMP%.%TIMESTAMP:::date-subseconds% %syslogtag% %syslogseverity-text%:%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n" :programname, startswith, "spice-vdagent" /var/log/spice-vdagent.log;SpiceTmpl [root@h101 ~]# [root@h101 ~]# vim /etc/rsyslog.d/haproxy.conf [root@h101 ~]# cat /etc/rsyslog.d/haproxy.conf $ModLoad imudp $UDPServerRun 514 local0.* /var/log/haproxy.log [root@h101 ~]# Item Comment $ModLoad imudp 加载UDP输入模块 imudp $UDPServerRun 514 使用UDP的514端口(一般默认是使用这个端口，也就是其它程序不明确指定的情况下也是尝试连接这个端口，如果改为其它端口，写日志的程序要在配置里明确指出，否则没法成功写入) local0.* /var/log/haproxy.log 自定义一个 local0 类别，这个类别的所有级别报警都记录到 /var/log/haproxy.log 文件中 3、重启rsylog、haproxy systemctl restart rsyslog /etc/init.d/haproxy reload 4、配置 logrotate [root@v-lb-1 logrotate.d]# cat haproxy /var/log/haproxy.log { rotate 5 copytruncate notifempty missingok sharedscripts compress maxsize 10M daily postrotate /bin/kill -HUP `ps -ef |grep rsyslogd |grep -v grep |awk '{print $2}'` 2> /dev/null || true endscript } __________________________________________________________________ haproxy 代理mysql 数据库健康检查授权 mysql> grant usage on *.* to haproxy_check@'192.168.0.78' identified by ''; haproxy配置 [root@v-haproxy-1 ~]# grep -v ^# /etc/haproxy/haproxy.cfg global # to have these messages end up in /var/log/haproxy.log you will # need to: # # 1) configure syslog to accept network log events. This is done # by adding the '-r' option to the SYSLOGD_OPTIONS in # /etc/sysconfig/syslog # # 2) configure local2 events to go to the /var/log/haproxy.log # file. A line like the following can be added to # /etc/sysconfig/syslog # # local2.* /var/log/haproxy.log # log 127.0.0.1 local2 #local0.* /var/log/haproxy/haproxy.log chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 65535 user haproxy group haproxy daemon # turn on stats unix socket stats socket /var/lib/haproxy/stats defaults mode tcp option dontlognull option forwardfor option redispatch retries 2 maxconn 65535 balance leastconn timeout connect 5000 listen admin_stats bind 0.0.0.0:1080 mode http stats refresh 30s stats uri /admin stats realm 17K\ Internat\ Haproxy stats auth admin:0admin stats hide-version stats admin if TRUE frontend mysql *:23 use_backend mysql10 backend mysql10 mode tcp option mysql-check user haproxy_check server mysql_192.168.1.10 192.168.1.10:3306 weight 1 check ___________________________________________________________________ CentOS 7上yum安装的Haproxy，默认没有记录日志。需要做一下配置才能记录日志。 1.创建日志文件/var/log/haproxy/haproxy.log [html] view plaincopy在CODE上查看代码片派生到我的代码片 cd /var/log sudo mkdir haproxy cd haproxy sudo touch haproxy.log sudo chmod a+w haproxy.log 2.开启rsyslog的haproxy日志记录功能 编辑/etc/rsyslog.conf文件，将 [html] view plaincopy在CODE上查看代码片派生到我的代码片 $ModLoad imudp $UDPServerRun 514 两行前的#去掉。 在 [html] view plaincopy在CODE上查看代码片派生到我的代码片 # Save boot messages also to boot.log local7.* /var/log/boot.log 之后添加 [html] view plaincopy在CODE上查看代码片派生到我的代码片 # Save haproxy log local0.* /var/log/haproxy/haproxy.log 修改/etc/sysconfig/rsyslog 文件，将 [html] view plaincopy在CODE上查看代码片派生到我的代码片 SYSLOGD_OPTIONS="" 改为 [html] view plaincopy在CODE上查看代码片派生到我的代码片 SYSLOGD_OPTIONS="-r -m 0 -c 2" 3.配置haproxy 修改/etc/haproxy/haproxy.cfg文件，在global区段添加 [html] view plaincopy在CODE上查看代码片派生到我的代码片 log 127.0.0.1 local0 重启rsyslog和haproxy服务，haproxy就能记录日志了。 ____________________________________________________________________ 101.129.1.210 10.110.86.216 -|10.110.86.193 -|10.110.86.194 _____________________________________________________________________ MySQL 相关配置 MySql Host is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' 解决方法 环境：linux，mysql5.5.21 错误：Host is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' 原因： 同一个ip在短时间内产生太多（超过mysql数据库max_connection_errors的最大值）中断的数据库连接而导致的阻塞； 解决方法： 1、提高允许的max_connection_errors数量（治标不治本）： ① 进入Mysql数据库查看max_connection_errors： show variables like '%max_connection_errors%'; ② 修改max_connection_errors的数量为1000： set global max_connect_errors = 1000; ③ 查看是否修改成功：show variables like '%max_connection_errors%'; 2、使用mysqladmin flush-hosts 命令清理一下hosts文件（不知道mysqladmin在哪个目录下可以使用命令查找：whereis mysqladmin）； ① 在查找到的目录下使用命令修改：/usr/bin/mysqladmin flush-hosts -h192.168.1.1 -P3308 -uroot -prootpwd; 备注： 其中端口号，用户名，密码都可以根据需要来添加和修改； 配置有master/slave主从数据库的要把主库和从库都修改一遍的（我就吃了这个亏明明很容易的几条命令结果折腾了大半天）； 第二步也可以在数据库中进行，命令如下：flush hosts; ______________________________________________________________________ HAproxy安装 #!/bin/bash # ## installHA.sh ## Created by maguirun@ctvit.com.cn ## Date: 2013-01-02 # echo "start install the HAProxy,please wait..." tar xzvf haproxy-1.4.10.tar.gz cd haproxy-1.4.10 mkdir -p /home/haproxy/{conf,logs} make TARGET=linux26 PREFIX=/home/haproxy USE_STATIC_PCRE=1 USE_LINUX_TPROXY=1 make install PREFIX=/home/haproxy/ sed -i 's/\-m 0/\-m 0 \-r \-x/' /etc/sysconfig/syslog echo "local3.* /home/haproxy/logs/haproxy.log" >> /etc/syslog.conf service syslog restart echo "The HAProxy has been installed!" # Linux VI 命令 /home/haproxy/conf/haproxy.cfg global log 127.0.0.1 local0 maxconn 4096 chroot /home/haproxy uid 99 gid 99 daemon nbproc 1 pidfile /home/haproxy/logs/haproxy.pid defaults log 127.0.0.1 local3 mode http #mode tcp option httplog option http-pretend-keepalive option httpclose option dontlognull option forwardfor option redispatch retries 2 maxconn 2000 balance roundrobin #balance leastconn contimeout 5000 clitimeout 50000 srvtimeout 50000 listen admin_stats bind 0.0.0.0:1080 mode http stats refresh 30s stats uri /haproxy-stats stats realm CCTV\ Internat\ Haproxy stats auth admin:admin stats hide-version stats admin if TRUE backend IRE mode http option httpchk server 192.168.168.110-ire.ctvit.com.cn 192.168.168.110:8080 check i nter 2s rise 2 fall 3 backend PIA mode http option httpchk server 192.168.168.111-pia.ctvit.com.cn 192.168.168.111:8086 check i nter 2s rise 2 fall 3 backend ITS mode http option httpchk server 192.168.168.112-its.ctvit.com.cn 192.168.168.112:10080 check inter 2s rise 2 fall 3 backend CMS mode http #option httpchk /tomcat.gif http-check expect status 200 server 192.168.168.115-cms.ctvit.com.cn 192.168.168.115:8080 check i nter 2s rise 2 fall 3 backend CCMS mode http option httpchk GET /client server 192.168.168.201-ccms.ctvit.com.cn 192.168.168.201:8080 check inter 2s rise 2 fall 3 frontend app_in bind *:80 acl ire url_dir ire acl pia url_dir pia acl its url_dir its acl cms url_dir CMS acl ccms url_dir client #acl chk_health srv_is_up(app_write/app_10.4.168.223) use_backend IRE if ire use_backend PIA if pia use_backend ITS if its use_backend CMS if cms use_backend CCMS if ccms default_backend CCMS #!/bin/sh # Name startHA.sh # Desc written to start HAProxy by maguirun. # Date 2011/12/19 ## _HA_HOME=/home/haproxy _PA_PID=`cat \$_HA_HOME/logs/haproxy.pid` echo ">> stoping the haproxy $_PA_PID,please wait..." killall haproxy echo ">> The haproxy is stop." echo ">> starting the haproxy,please wail..." /home/haproxy/sbin/haproxy -f /home/haproxy/conf/haproxy.cfg ps -ef |grep haproxy echo ">> The haproxy is running." # Linux VI 命令 /etc/rsyslog.conf # Save Haproxy messages also to haproxy.log local3.* /var/log/haproxy.log # service rsyslogd restart _______________________________________________________________________ HAProxy负载均衡保持客户端和服务器Session亲缘性的三种方式 haproxy负载均衡保持客户端和服务器Session亲缘性的三种方式: haproxy 1 用户IP 识别 haroxy 将用户IP经过hash计算后 指定到固定的真实服务器上（类似于nginx 的IP hash 指令） 配置指令 balance source 2 cookie 识别 haproxy 将WEB服务端发送给客户端的cookie中插入(或添加加前缀)haproxy定义的后端的服务器COOKIE ID。 配置指令例举 cookie SESSION_COOKIE insert indirect nocache 用firebug可以观察到用户的请求头的cookie里 有类似" Cookie jsessionid=0bc588656ca05ecf7588c65f9be214f5; SESSION_COOKIE=app1" SESSION_COOKIE=app1就是haproxy添加的内容 3 session 识别 haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。 配置指令例举 appsession JSESSIONID len 64 timeout 5h request-learn #haproxy -f haproxy.cfg -V #haproxy.cfg global log 127.0.0.1 local0 info maxconn 4096 user haproxy group haproxy daemon nbproc 1 pidfile /var/run/haproxy.pid defaults mode http maxconn 2000 contimeout 5000 clitimeout 30000 srvtimeout 30000 option httplog option redispatch option abortonclose retries 3 listen admin_stats bind 113.106.185.245:443 mode http log 127.0.0.1 local0 err stats uri /qhappy_stats stats realm itindex.net\ Qhappy stats auth qhappy:qhappy stats refresh 5s listen site_status bind 113.106.185.245:445 mode http log 127.0.0.1 local0 err monitor-uri /site_status frontend WEB_SITE bind 0.0.0.0:8080 mode http log global option httplog option httpclose option forwardfor acl COOKIE hdr_reg(host) -i ^(cookie.itindex.net) acl SOURCE hdr_reg(host) -i ^(sourceip. itindex .net) acl APPSESSION hdr_reg(host) -i ^(appsession. itindex .net) acl NOSESSION hdr_reg(host) -i ^(nosession. itindex .net) use_backend COOKIE_srv if COOKIE use_backend SOURCE_srv if SOURCE use_backend APPSESSION_srv if APPSESSION use_backend NOSESSION_srv if NOSESSION # default_backend ai_server backend COOKIE_srv mode http cookie SESSION_COOKIE insert indirect nocache server REALsrv_70 184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1 server REALsrv_120 220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1 backend SOURCE_srv mode http balance source server REALsrv_70 184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1 server REALsrv_120 220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1 backend APPSESSION_srv mode http appsession JSESSIONID len 64 timeout 5h request-learn server REALsrv_70 184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1 server REALsrv_120 220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1 backend NOSESSION_srv mode http balance roundrobin server REALsrv_70 184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1 server REALsrv_120 220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1 backend ai_server mode http balance roundrobin cookie SERVERID server REALsrv_70 184.82.239.70:80 cookie 2 check inter 1500 rise 3 fall 3 weight 1 server REALsrv_120 220.162.237.120:80 cookie 1 check inter 1500 rise 3 fall 3 weight 1 #Cookie listen appli1-rewrite 0.0.0.0:80 mode http option httplog option dontlognull option httpclose option forwardfor cookie SESSION_COOKIE insert indirect nocache #balance roundrobin server app1_1 172.20.37.249:8080 cookie app1inst1 check inter 2000 rise 2 fall 5 server app1_2 172.20.12.145:80 cookie app1inst2 check inter 2000 rise 2 fall 5 #IP listen appli1 0.0.0.0:90 mode http option httplog option dontlognull log 127.0.0.1 local3 cookie JSESSIONID rewrite balance source option httpchk GET /payCardSys/login.jsp stats uri /stats stats auth admin:admin server app1_1 10.112.56.66:6601 cookie app1inst1 check inter 2000 rise 2 fall 5 server app1_2 10.112.56.67:6702 cookie app1inst2 check inter 2000 rise 2 fall 5 ______________________________________________________________________________________ http://francs3.blog.163.com/blog/static/4057672720125315352442/ ________________________________________________________________________ Using HAproxy as a reverse proxyHAproxy has a great feature set when used in conjunction with Wt: Uses async I/O and thus handles thousands of connections without any problem. Just like Wt! Supports reverse proxying of WebSocket connections (as per draft-76). Can be configured to use session affinity without needing cookies. You need a fairly recent of haproxy for the options 'http-server-close' and 'http-pretend-keepalive' to work, which is needed for reliable load-balancing. Basic setup global log 127.0.0.1 local0 log 127.0.0.1 local1 notice maxconn 4096 user haproxy group haproxy daemon defaults log global mode http option httplog option dontlognull option http-server-close option http-pretend-keepalive option forwardfor option originalto retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 50000 srvtimeout 50000 listen 0.0.0.0:8181 server srv1 0.0.0.0:9090 check Using session affinity All of the built-in mechanisms in HAproxy for session affinity using the appsession option rely on cookies, but cookies are not our preferred method since this does not give an intuitive user experience (e.g. a user cannot open multiple sessions), are not entirely reliable (a user can disable cookies) and a source of security risks (CSRF). Luckily there is a work-around: using Wt's ability to generate session-id's that have a prefix which identifies the back-end, we can have HAproxy match on this prefix in the request URL and send the requests to the correct server. Below is an example configuration for two back-end servers. global log 127.0.0.1 local0 log 127.0.0.1 local1 notice maxconn 4096 user haproxy group haproxy daemon defaults log global mode http option httplog option dontlognull option http-server-close option http-pretend-keepalive option forwardfor option originalto retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 50000 srvtimeout 50000 frontend wt bind 0.0.0.0:80 acl srv1 url_sub wtd=wt1 acl srv2 url_sub wtd=wt2 acl srv1_up nbsrv(bck1) gt 0 acl srv2_up nbsrv(bck2) gt 0 use_backend bck1 if srv1_up srv1 use_backend bck2 if srv2_up srv2 default_backend bck_lb backend bck_lb balance roundrobin server srv1 0.0.0.0:9090 track bck1/srv1 server srv2 0.0.0.0:9091 track bck2/srv2 backend bck1 balance roundrobin server srv1 0.0.0.0:9090 check backend bck2 balance roundrobin server srv2 0.0.0.0:9091 check _________________________________________________________________________ CHAPTER 7. USING ACLS AND PATTERN EXTRACTION 160 block if HTTP_URL_STAR !METH_OPTIONS || METH_POST missing_cl block if METH_GET HTTP_CONTENT block unless METH_GET or METH_POST or METH_OPTIONS To select a different backend for requests to static contents on the "www" site and to every request on the "img", "video", "download" and "ftp" hosts : acl acl acl acl url_static url_static host_www host_static path_beghaproxy /static /images /img /css path_end .gif .png .jpg .css .js hdr_beg(host) -i www hdr_beg(host) -i img. video. download. ftp. # now use backend "static" for all static-only hosts, and for static urls # of host "www". Use backend "www" for the rest. use_backend static if host_static or host_www url_statichaproxy use_backend www if host_www It is also possible to form rules using "anonymous ACLs". Those are unnamed ACL expressions that are built on the fly without needing to be declared. They must be enclosed between braces, with a space before and after eac __________________________________________________________________________ disable server <backend>/<server> Mark the server DOWN for maintenance. In this mode, no more checks will be performed on the server until it leaves maintenance. If the server is tracked by other servers, those servers will be set to DOWN during the maintenance. In the statistics page, a server DOWN for maintenance will appear with a __________________________________________________________________________ option httpchk option httpchk <uri> option httpchk <method> <uri> option httpchk <method> <uri> <version> Enable HTTP protocol to check on the servers health May be used in sections : defaults | frontend | listen | backend yes | no | yes | yes Arguments : <method> is the optional HTTP method used with the requests. When not set, the "OPTIONS" method is used, as it generally requires low server processing and is easy to filter out from the logs. Any method may be used, though it is not recommended to invent non-standard ones. <uri> is the URI referenced in the HTTP requests. It defaults to " / " which is accessible by default on almost any server, but may be changed to any other URI. Query strings are permitted. <version> is the optional HTTP version string. It defaults to "HTTP/1.0" but some servers might behave incorrectly in HTTP 1.0, so turning it to HTTP/1.1 may sometimes help. Note that the Host field is mandatory in HTTP/1.1, and as a trick, it is possible to pass it after "\r\n" following the version string. By default, server health checks only consist in trying to establish a TCP connection. When "option httpchk" is specified, a complete HTTP request is sent once the TCP connection is established, and responses 2xx and 3xx are considered valid, while all other ones indicate a server failure, including the lack of any response. The port and interval are specified in the server configuration. This option does not necessarily require an HTTP backend, it also works with plain TCP backends. This is particularly useful to check simple scripts bound to some dedicated ports using the inetd daemon. Examples : # Relay HTTPS traffic to Apache instance and check service availability # using HTTP request "OPTIONS * HTTP/1.1" on port 80. backend https_relay mode tcp option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www server apache1 192.168.1.1:443 check port 80 _______________________________________________________________________________________________ centos下haproxy日志的配置 时间:2015-09-18 01:22来源:blog.51cto.com 作者:haodiandian 的BLOG 举报 点击:620次 涉及到的配置文件如下 1) /etc/haproxy/haproxy.conf //这个是haproxy程序的主配置文件，具体路径可以随意指定,主要是下面这句话 log localhost local0 2) /etc/rsyslog.conf //这个配置文件不用动，默认会有下面的设置，会读取 /etc/rsyslog.d/*.conf目录 //下的配置文件 $IncludeConfig /etc/rsyslog.d/*.conf 3) /etc/rsyslog.d/haproxy.conf //这个文件是需要我们手动创建的，内容如下： cat /etc/rsyslog.d/haproxy.conf $ModLoad imudp $UDPServerRun 514 $template Haproxy,"%rawmsg% \n" local0.=info -/var/log/haproxy.log;Haproxy local0.notice -/var/log/haproxy-status.log;Haproxy ### keep logs in localhost ## local0.* ~ 4) /etc/sysconfig/rsyslog 内容如下 # Options for rsyslogd # Syslogd options are deprecated since rsyslog v3. # If you want to use them, switch to compatibility mode 2 by "-c 2" # See rsyslogd(8) for more details SYSLOGD_OPTIONS="-c 2 -r -m 0" 备注: #-c 2 使用兼容模式，默认是 -c 5 #-r 开启远程日志 #-m 0 标记时间戳。单位是分钟，为0时，表示禁用该功能 好了，日志配置主要就是涉及到这几个文件了。 另外，再重启下rsyslog和haproxy服务就可以了 centos 6: /etc/init.d/rsyslog restart centos 7: systemctl restart rsyslog killlall -9 haproxy && haproxy -f /etc/haproxy/haproxy.conf 最后，最重要的一点，一定要把iptables udp 514端口开起来 iptables -I INPUT -m udp -p udp --dport 514 -j ACCEPT 否则有可能会报一堆错误，类似下面这样子： sendto logger #0 failed: operation not permitted (errno=1) ____________________________________________________________________________________ Enable HAProxy logging on CentOS By default, HAProxy will not log to files unless we make some modifications 1. Create rsyslog configuration file nano /etc/rsyslog/haproxy.conf Add these lines to the file # Enable UDP port 514 to listen to incoming log messages from haproxy $ModLoad imudp $UDPServerRun 514 $template Haproxy,"%msg%\n" local0.=info -/var/log/haproxy/haproxy.log;Haproxy local0.notice -/var/log/haproxy/admin.log;Haproxy # don't log anywhere else local0.* ~ Restart rsyslog service /etc/init.d/rsyslog restart Ref: http://blog.hintcafe.com/post/33689067443/haproxy-logging-with-rsyslog-on-linux 2. Modify the log rotate config to match the new folder: nano /etc/logrotate.d/haproxy Change /var/log/haproxy.log { daily rotate 10 missingok [...] to /var/log/haproxy/*.log { daily rotate 10 missingok [...] Now we can check if HAProxy logging is working. tail -f /var/log/haproxy/haproxy.log ________________________________________________________________________________________________________ haproxy 日志格式说明 >>> Feb 6 12:14:14 localhost \ haproxy[14389]: 10.0.1.2:33317 [06/Feb/2009:12:14:14.655] http-in \ static/srv1 10/0/30/69/109 200 2750 - - ---- 1/1/1/1/0 0/0 {1wt.eu} \ {} "GET /index.html HTTP/1.1" Field Format Extract from the example above 1 process_name '[' pid ']:' haproxy[14389]: 2 client_ip ':' client_port 10.0.1.2:33317 3 '[' request_date ']' [06/Feb/2009:12:14:14.655] 4 frontend_name http-in 5 backend_name '/' server_name static/srv1 6 TR '/' Tw '/' Tc '/' Tr '/' Ta* 10/0/30/69/109 7 status_code 200 8 bytes_read* 2750 9 captured_request_cookie - 10 captured_response_cookie - 11 termination_state ---- 12 actconn '/' feconn '/' beconn '/' srv_conn '/' retries* 1/1/1/1/0 13 srv_queue '/' backend_queue 0/0 14 '{' captured_request_headers* '}' {haproxy.1wt.eu} 15 '{' captured_response_headers* '}' {} 16 '"' http_request '"' "GET /index.html HTTP/1.1" Detailed fields description : - "client_ip" is the IP address of the client which initiated the TCP connection to haproxy. If the connection was accepted on a UNIX socket instead, the IP address would be replaced with the word "unix". Note that when the connection is accepted on a socket configured with "accept-proxy" and the PROXY protocol is correctly used, or with a "accept-netscaler-cip" and the NetScaler Client IP insetion protocol is correctly used, then the logs will reflect the forwarded connection's information. - "client_port" is the TCP port of the client which initiated the connection. If the connection was accepted on a UNIX socket instead, the port would be replaced with the ID of the accepting socket, which is also reported in the stats interface. - "request_date" is the exact date when the first byte of the HTTP request was received by haproxy (log field %tr). - "frontend_name" is the name of the frontend (or listener) which received and processed the connection. - "backend_name" is the name of the backend (or listener) which was selected to manage the connection to the server. This will be the same as the frontend if no switching rule has been applied. - "server_name" is the name of the last server to which the connection was sent, which might differ from the first one if there were connection errors and a redispatch occurred. Note that this server belongs to the backend which processed the request. If the request was aborted before reaching a server, "<NOSRV>" is indicated instead of a server name. If the request was intercepted by the stats subsystem, "<STATS>" is indicated instead. - "TR" is the total time in milliseconds spent waiting for a full HTTP request from the client (not counting body) after the first byte was received. It can be "-1" if the connection was aborted before a complete request could be received or the a bad request was received. It should always be very small because a request generally fits in one single packet. Large times here generally indicate network issues between the client and haproxy or requests being typed by hand. See "Timers" below for more details. - "Tw" is the total time in milliseconds spent waiting in the various queues. It can be "-1" if the connection was aborted before reaching the queue. See "Timers" below for more details. - "Tc" is the total time in milliseconds spent waiting for the connection to establish to the final server, including retries. It can be "-1" if the request was aborted before a connection could be established. See "Timers" below for more details. - "Tr" is the total time in milliseconds spent waiting for the server to send a full HTTP response, not counting data. It can be "-1" if the request was aborted before a complete response could be received. It generally matches the server's processing time for the request, though it may be altered by the amount of data sent by the client to the server. Large times here on "GET" requests generally indicate an overloaded server. See "Timers" below for more details. - "Ta" is the time the request remained active in haproxy, which is the total time in milliseconds elapsed between the first byte of the request was received and the last byte of response was sent. It covers all possible processing except the handshake (see Th) and idle time (see Ti). There is one exception, if "option logasap" was specified, then the time counting stops at the moment the log is emitted. In this case, a '+' sign is prepended before the value, indicating that the final one will be larger. See "Timers" below for more details. - "status_code" is the HTTP status code returned to the client. This status is generally set by the server, but it might also be set by haproxy when the server cannot be reached or when its response is blocked by haproxy. - "bytes_read" is the total number of bytes transmitted to the client when the log is emitted. This does include HTTP headers. If "option logasap" is specified, the this value will be prefixed with a '+' sign indicating that the final one may be larger. Please note that this value is a 64-bit counter, so log analysis tools must be able to handle it without overflowing. - "captured_request_cookie" is an optional "name=value" entry indicating that the client had this cookie in the request. The cookie name and its maximum length are defined by the "capture cookie" statement in the frontend configuration. The field is a single dash ('-') when the option is not set. Only one cookie may be captured, it is generally used to track session ID exchanges between a client and a server to detect session crossing between clients due to application bugs. For more details, please consult the section "Capturing HTTP headers and cookies" below. - "captured_response_cookie" is an optional "name=value" entry indicating that the server has returned a cookie with its response. The cookie name and its maximum length are defined by the "capture cookie" statement in the frontend configuration. The field is a single dash ('-') when the option is not set. Only one cookie may be captured, it is generally used to track session ID exchanges between a client and a server to detect session crossing between clients due to application bugs. For more details, please consult the section "Capturing HTTP headers and cookies" below. - "termination_state" is the condition the session was in when the session ended. This indicates the session state, which side caused the end of session to happen, for what reason (timeout, error, ...), just like in TCP logs, and information about persistence operations on cookies in the last two characters. The normal flags should begin with "--", indicating the session was closed by either end with no data remaining in buffers. See below "Session state at disconnection" for more details. - "actconn" is the total number of concurrent connections on the process when the session was logged. It is useful to detect when some per-process system limits have been reached. For instance, if actconn is close to 512 or 1024 when multiple connection errors occur, chances are high that the system limits the process to use a maximum of 1024 file descriptors and that all of them are used. See section 3 "Global parameters" to find how to tune the system. - "feconn" is the total number of concurrent connections on the frontend when the session was logged. It is useful to estimate the amount of resource required to sustain high loads, and to detect when the frontend's "maxconn" has been reached. Most often when this value increases by huge jumps, it is because there is congestion on the backend servers, but sometimes it can be caused by a denial of service attack. - "beconn" is the total number of concurrent connections handled by the backend when the session was logged. It includes the total number of concurrent connections active on servers as well as the number of connections pending in queues. It is useful to estimate the amount of additional servers needed to support high loads for a given application. Most often when this value increases by huge jumps, it is because there is congestion on the backend servers, but sometimes it can be caused by a denial of service attack. - "srv_conn" is the total number of concurrent connections still active on the server when the session was logged. It can never exceed the server's configured "maxconn" parameter. If this value is very often close or equal to the server's "maxconn", it means that traffic regulation is involved a lot, meaning that either the server's maxconn value is too low, or that there aren't enough servers to process the load with an optimal response time. When only one of the server's "srv_conn" is high, it usually means that this server has some trouble causing the requests to take longer to be processed than on other servers. - "retries" is the number of connection retries experienced by this session when trying to connect to the server. It must normally be zero, unless a server is being stopped at the same moment the connection was attempted. Frequent retries generally indicate either a network problem between haproxy and the server, or a misconfigured system backlog on the server preventing new connections from being queued. This field may optionally be prefixed with a '+' sign, indicating that the session has experienced a redispatch after the maximal retry count has been reached on the initial server. In this case, the server name appearing in the log is the one the connection was redispatched to, and not the first one, though both may sometimes be the same in case of hashing for instance. So as a general rule of thumb, when a '+' is present in front of the retry count, this count should not be attributed to the logged server. - "srv_queue" is the total number of requests which were processed before this one in the server queue. It is zero when the request has not gone through the server queue. It makes it possible to estimate the approximate server's response time by dividing the time spent in queue by the number of requests in the queue. It is worth noting that if a session experiences a redispatch and passes through two server queues, their positions will be cumulated. A request should not pass through both the server queue and the backend queue unless a redispatch occurs. - "backend_queue" is the total number of requests which were processed before this one in the backend's global queue. It is zero when the request has not gone through the global queue. It makes it possible to estimate the average queue length, which easily translates into a number of missing servers when divided by a server's "maxconn" parameter. It is worth noting that if a session experiences a redispatch, it may pass twice in the backend's queue, and then both positions will be cumulated. A request should not pass through both the server queue and the backend queue unless a redispatch occurs. - "captured_request_headers" is a list of headers captured in the request due to the presence of the "capture request header" statement in the frontend. Multiple headers can be captured, they will be delimited by a vertical bar ('|'). When no capture is enabled, the braces do not appear, causing a shift of remaining fields. It is important to note that this field may contain spaces, and that using it requires a smarter log parser than when it's not used. Please consult the section "Capturing HTTP headers and cookies" below for more details. - "captured_response_headers" is a list of headers captured in the response due to the presence of the "capture response header" statement in the frontend. Multiple headers can be captured, they will be delimited by a vertical bar ('|'). When no capture is enabled, the braces do not appear, causing a shift of remaining fields. It is important to note that this field may contain spaces, and that using it requires a smarter log parser than when it's not used. Please consult the section "Capturing HTTP headers and cookies" below for more details. - "http_request" is the complete HTTP request line, including the method, request and HTTP version string. Non-printable characters are encoded (see below the section "Non-printable characters"). This is always the last field, and it is always delimited by quotes and is the only one which can contain quotes. If new fields are added to the log format, they will be added before this field. This field might be truncated if the request is huge and does not fit in the standard syslog buffer (1024 characters). This is the reason why this field must always remain the last one.
Cloudera Hadoop
Bmon安装
0
赞
1 人读过
新浪微博
微信
更多分享
腾讯微博
QQ空间
人人网
文档导航
myron