haproxy的错误页面定义,日志相关配置
首先来说说错误页面的配置吧;haproxy同nginx是一样可自定义错误页面;在nginx里我们用error_page 指令来指定对应错误状态码加location,根据错误状态码指定的location来指定对应错误状态码的状态页面文件;haproxy自定义错误页面的思想类似,不同的是nginx作为web服务器可以自定义404错误页面,而haproxy通常作为代理服务器,对于404错误页面通常不会由haproxy自己指定,因为haproxy作为代理服务器对于后端server的资源是否能够找到,它不知道;即便我们在配置中指定了404错误对应的响应页面,在haproxy重启后是不会生效的;haproxy指定错误页面的方式两种,第一种是指定本地文件系统文件作为对应错误状态码的错误页;第二种是指定对应错误状态码跳转的url;
errorfile <code> <file>:指定对应错误状态码对应文件系统上的文件作为该状态码响应的页面
示例:自定义错误403的错误页面
提示:为了能够模仿出403错误,上面使用了acl来拒绝源地址为192.168.0.232的访问;后面我们会说acl的用法;上图红框中的内容就是表示对于错误403响应页面上/etc/haproxy/error403.html;
测试:在192.168.0.232主机上用浏览器访问haproxy对外提供服务端接口,看看是否响应我们自定义的页面?
提示:从上面的测试结果看,haproxy是能够把我们指定错误状态码对应文件内容响应给我们;这里挺奇怪的在消息头里只看得到请求报文,没有响应报文;
示例:指定403错误页面跳转至nginx.org/aaa.html
提示:红框中的配置就表示对于403错误就跳转到指定http://nginx.org/aaa.html
测试:在232主机*问192.168.0.22看看是否跳转到nginx.org/aaa.html?
提示:errorloc和errorloc302都是同样的效果,都是以临时重定向到指定的url上;这里还需要注意一点,这两种方式都是跳转前请求的方法是什么,跳转对应url也是同样的方法;这样一来对于其他非get方法请求出现403错误码的时候,对应的错误页就无法正常处理(通常只允许get方法去请求别的url);比如跳转前用put方法,出现错误403后,按照上面的配置,对应指定的错误页的url也会用put方法去请求;为了解决这样的问题,我们这里需要用到errorloc303来指定;该指令的意思是返回303响应码;如果请求前非get方法,而出现对应错误后,用get方法去请求对应错误状态码指定的url;
示例:非get方法错误页面重定向到其他url上
提示:以上配置就表示如果我们用非get方法请求某资源,出现403错误后,返回303状态码;303表示请求重定向页面的方法要总是使用get方法;
测试:先使用errorloc302指定url跳转,然后在浏览器上跳转前使用put方法请求,看看跳转后到指定url看看使用的什么方法?
提示:可以看到当我们用put方法请求192.168.0.22时,跳转到指定的url也是用的put方法;
测试:用errorloc303指定跳转url,然后用put方法请求192.168.0.22看看跳转url使用什么方法?
提示:可以看到用errorloc303指定错误url后,跳转指定url不是跳转前的put方法请求,而是get;
以上就是haproxy关于错误页面的定义的配置,更多说明请参考官方文档;说了haproxy的错误页面配置后,接下来在来了解下haproxy的日志;
log:启用事件和流量的每个实例日志记录。
no log:关闭日志记录;
log global:调用全局配置段中日志的定义;
log<address> [len <length>] <facility> [<level> [<minlevel>]]:定义一个用于接收haproxy日志的rsyslog服务器地址,facility;默认是发往本机的rsyslog服务器上的local2上;有关rsyslog的相关说明请参考;
log-format <string>:设定日志格式;日志格式的设定变量表请参照下表
+---+------+-----------------------------------------------+-------------+
| r | var | field name (8.2.2 and 8.2.3 for description) | type |
+---+------+-----------------------------------------------+-------------+
| | %o | special variable, apply flags on all next var | |
+---+------+-----------------------------------------------+-------------+
| | %b | bytes_read (from server to client) | numeric |
| h | %cc | captured_request_cookie | string |
| h | %cs | captured_response_cookie | string |
| | %h | hostname | string |
| | %id | unique-id | string |
| | %st | status_code | numeric |
| | %t | gmt_date_time | date |
| | %tc | tc | numeric |
| | %tl | local_date_time | date |
| h | %tq | tq | numeric |
| h | %tr | tr | numeric |
| | %ts | timestamp | numeric |
| | %tt | tt | numeric |
| | %tw | tw | numeric |
| | %u | bytes_uploaded (from client to server) | numeric |
| | %ac | actconn | numeric |
| | %b | backend_name | string |
| | %bc | beconn (backend concurrent connections) | numeric |
| | %bi | backend_source_ip (connecting address) | ip |
| | %bp | backend_source_port (connecting address) | numeric |
| | %bq | backend_queue | numeric |
| | %ci | client_ip (accepted address) | ip |
| | %cp | client_port (accepted address) | numeric |
| | %f | frontend_name | string |
| | %fc | feconn (frontend concurrent connections) | numeric |
| | %fi | frontend_ip (accepting address) | ip |
| | %fp | frontend_port (accepting address) | numeric |
| | %ft | frontend_name_transport ('~' suffix for ssl) | string |
| | %hr | captured_request_headers default style | string |
| | %hrl | captured_request_headers clf style | string list |
| | %hs | captured_response_headers default style | string |
| | %hsl | captured_response_headers clf style | string list |
| | %ms | accept date milliseconds (left-padded with 0) | numeric |
| | %pid | pid | numeric |
| h | %r | http_request | string |
| | %rc | retries | numeric |
| | %rt | request_counter (http req or tcp session) | numeric |
| | %s | server_name | string |
| | %sc | srv_conn (server concurrent connections) | numeric |
| | %si | server_ip (target address) | ip |
| | %sp | server_port (target address) | numeric |
| | %sq | srv_queue | numeric |
| s | %sslc| ssl_ciphers (ex: aes-sha) | string |
| s | %sslv| ssl_version (ex: tlsv1) | string |
| | %t | date_time (with millisecond resolution) | date |
| | %ts | termination_state | string |
| h | %tsc | termination_state with cookie status | string |
+---+------+-----------------------------------------------+-------------+
capture cookie <name> len <length>:捕获并记录请求报文和响应报文中的cookie信息
capture request header <name> len <length>:捕获并记录指定请求标头的最后一次出现
capture response header <name> len <length>:捕获并记录指定响应标头的最后一次出现
结合上面的内容,我们就可以自定义访问日志了;通常我们通过capture去捕获对应首部的信息,然后通过上面的变量定义成日志格式
示例:
测试:用浏览器访问对应haproxy的前端,看看日志格式
提示:可以看到我们访问对应haproxy的前端,日志就和默认的日志不一样了;日志格式中的变来可参照上边的表去找对应表示什么;
转自:https://www.cnblogs.com/qiuhom-1874/p/12797913.html
上一篇: shell脚本if结构条件句知识与实践
下一篇: 移动端仿京东轮播图实例教程