搜索文章 Ctrl K

3-4-7-HAProxy高级功能与配置之Web服务器状态监控

熊 0 阅读 Linux集群服务

  • Haproxy服务器状态监测共有三种监测方式

    • 基于四层的传输端口做状态监测

    • 基于指定URI做状态监测

    • 基于指定URI的request请求头部内容做状态监测

  • option httpchk选项说明 : 启用HTTP协议以检查服务器运行状况

    • option httpchk

    • option httpchk <uri>

    • option httpchk <method> <uri>

    • option httpchk <method> <uri> <version>

      defaults

      frontend

      listen

      backend

      yes ✅

      no ❌

      yes ✅

      yes ✅

      此指令表示基于http协议来做健康状况检查 , 只有返回状态码为2xx或3xx的才认为是健康的 , 其余所有状态码都认为不健康。不设置该选项时 , 默认采用tcp做健康检查 , 只要能建立tcp就表示健康。

      • uri：检查的uri路径 , 默认为/。接受带有查询参数的uri

      • method：http检查时使用的METHOD。不指定时默认为OPTIONS方法 , 也建议采用此方法 , 因为该请求方法对服务器造成的资源损耗最小。

      • version : 检查的http协议版本 , 默认为http/1.0 , 但现在很多都采用HTTP/1.1 , 因此此处检查版本需要修改为HTTP/1.1 , 但对于该版本的HTTP协议来说 ,还强制要求指定Host ,中间使用\r\n隔离。

1. 基于四层的传输端口做状态监测

在haproxy的listen端配置:

server web01 172.30.1.106:80 check port 9000 addr 172.30.1.107 inter 3s fall 3 rise 5 weight 1

优点 : 只需要监控目标服务器的端口 , 比如在LNMP架构中 , 我们将haproxy请求打到nginx服务器上时 , 但与此同时我们要监控PHP进程是否正常。因此我们要单独监测一下PHP的端口 , 若端口不正常说明PHP服务存在问题 , 从而haproxy可以及时将该节点标记未不可用状态 , 让新的请求打到服务正常的节点上。

缺点 : 有时候服务端口和进程都是存在的 , 但是就是不正常提供服务 , 尤其是Java程序很容易出现类似的案例 , 这个时候如果我们使用基于端口的监听方式明显就不太合适了。

配置示例

listen web_port
        bind 0.0.0.0:80
        mode http
        log global
        balance random
        server web1 192.168.194.136:8080  check  inter 3000 fall 2 rise 5
        server web2 192.168.194.128:8080  check addr 192.168.194.200 port 9000  inter 3000 fall 2 rise 5
        #web2主要检测192.168.194.200服务器中的9000端口

2. 基于指定URI做状态监测

优点 : 可以模拟客户端去访问服务端 , 如果响应状态码是正常的说明服务端处于正常工作状态 , 从而避免了基于端口监控的弊端。

缺点 : 需要单独创建一个资源文件 , 占用磁盘空间 , 而且该文件在实际业务中并不会使用 , 该文件只是用来监测服务是否正常工作 , 因此建议将资源文件设置较小即可。

配置示例

#后端服务器配置
[root@centos7 ~]# echo hello > /var/www/html/monitor/index.html
[root@centos7 ~]# cat /var/www/html/monitor/index.html
hello
​
#haproxy配置文件设置
listen web_port
        bind 0.0.0.0:80
        mode http
        log global
        balance random
        option httpchk GET /monitor/index.html 
        #option httpchk GET /monitor/index.html HTTP/1.0
        server web1 192.168.194.136:8080  check  inter 3000 fall 2 rise 5
        server web2 192.168.194.128:8080  check  inter 3000 fall 2 rise 5

3. 基于指定URI的request请求头部内容做状态监测

优点 : 和上面所说的"基于指定URI做状态监测"原理一样 , 只不过它做了一个优化操作 , 就是不要消息体(body)部分 , 只返回给haproxy响应头部(head)信息即可 , 从而节省了后端web服务器的网络I/O。

缺点 : 同上面所说的"基于指定URI做状态监测" , 不过相对于以上说的两种监测方案 , 这种监测我还是推荐在生产环境中使用的。

配置示例

listen web_port
        bind 0.0.0.0:80
        mode http
        log global
        balance random
        option httpchk HEAD /monitor/index.html HTTP/1.0\r\nHost:\ www.baidu.com\r\nUser-Agent:\ haproxy_check
        #http-check expect status 404
        server web1 192.168.194.136:8081  check  inter 3000 fall 2 rise 5
        server web2 192.168.194.128:8080  check  inter 3000 fall 2 rise 5

需要说明的一点是,option httpchk HEAD后续Host以及User-Agent都是作为请求报文存在的 , 如果需要验证后面这些配置是否生效,可以查看后端服务器的日志信息

image-20220630115911546

4. http-check

  • http-check comment <string> : 为以下http-check规则定义注释,如果失败 , 则在日志中报告出来。仅在connect、send、expect中生效。sections : defaults,listen,backend

  • http-check disable-on-404 : 在HTTP/404 响应运行状况检查时启用维护模式 , 此维护模式下服务器报告NOLB状态。该选项仅与httpchk选项结合使用 。如果此选项与http check expect一起使用 , 则其优先级高于它 , 因此404响应仍将被视为软停止。此选项仅适用于评估运行的服务器。

    image-20220708115026561

  • http-check connect : 打开新连接以执行HTTP运行状况检查。sections :defaults,listen,backend

    http-check connect [default] [port <expr>] [addr <ip>] [send-proxy]
                   [via-socks4] [ssl] [sni <sni>] [alpn <alpn>] [linger]
                   [proto <name>] [comment <msg>]

    • default : 使用server行中使用的默认选项来做健康检测。该服务器选项仅在为重新定义时使用

    • port <expr> : 检测的端口号

    • add <ip> : 通过指定的IP地址做健康检测

    • ssl : 开启加密连接

    • sni <sni> : 指定特殊的SNI通过SSL 进行健康检测

    就像tcp-check健康检查一样 , 可以用于执行HTTP健康检查配置连接。这个指令也应该被用来描述一个涉及多个请求/响应交换的场景 , 可能是在不同的端口或不同的服务器。

    当服务器线上没有配置TCP端口时 , 也没有服务器端口指令 , 那么http-check检查序列的第一步必须指定带有http-check connect的端口。

    在http-check规则集中需要一个“connect” , 它也是必须启动的带有“connect”规则的规则集。目的是确保管理人员知道他们做的。

    # check HTTP and HTTPs services on a server.
# first open port 80 thanks to server line port directive, then
# tcp-check opens port 443, ciphered and run a request on it:
option httpchk
​
http-check connect
http-check send meth GET uri / ver HTTP/1.1 hdr host haproxy.1wt.eu
http-check expect status 200-399
http-check connect port 443 ssl sni haproxy.1wt.eu
http-check send meth GET uri / ver HTTP/1.1 hdr host haproxy.1wt.eu
http-check expect status 200-399
​
server www 10.0.0.1 check port 80

  • http-check expect : 使HTTP健康检查考虑响应指定的内容或特定的状态代码。在http-check规则集中 , 最后一个expect规则可能是隐式的。如果在最后一个http-check send之后没有指定expect规则 , 那么将定义一个隐式的expect规则来匹配2xx或3xx状态码。这意味着如果根本没有http-check规则 , 而只设置了option httpchk时 , 也会定义此规则。sections :defaults,listen,backend

    http-check expect [min-recv <int>] [comment <msg>]
                  [ok-status <st>] [error-status <st>] [tout-status <st>]
                  [on-success <fmt>] [on-error <fmt>] [status-code <expr>]
                  [!] <match> <pattern>

    • min-recv <int> : 可选参数。可以定义评估当前expect规则所需的最小数据量。如果接收的字节数在这个限制下 , 检查将等待更多的数据。此选项可用于解析一些不明确的匹配规则 , 或避免对已知仍不完整的内容执行代价高昂的regex匹配。如果使用精确字符串 , 则使用字符串长度与该参数之间的最小值。如果设置为-1 , 则忽略此参数。如果expect规则不匹配 , 检查将等待更多数据。如果设置为0 , 则评价结果始终是决定性的。

    • ok-status <st> : 是可选的 , 如果expect的规则被成功评估 , 并且它是tcp-check规则集中的最后一个规则 , 则可用于设置检查状态。支持“L7OK”、“L7OKC”、“L6OK”和“L4OK”:

      • L7OK : 检查通过第七层

      • L7OKC : 在第7层检查是否有条件地传递 , 设置服务器为NOLB状态。

      • L6OK:检查通过了第6层

      • L4OK :检查通过第4层

    • error-status <st> : 是可选的 。设置在expect规则求值期间发生错误时,可以用于的检查状态。

      • L7OKC:在第7层检查是否有条件地传递 , 设置服务器为NOLB状态。

      • L7RSP: layer 7 invalid response - protocol error

      • L7STS :七层响应错误 , 如HTTP 5xx

      • L6RSP : layer 6 invalid response - protocol error

      • L4CON: 1-4层连接问题

        缺省情况下 , 使用L7RSP。

    • tout-status <st> : 可选项。在expect规则求值期间发生超时 ,设置检测状态。支持L7TOUT、L6TOUT和L4TOUT:

      • L7TOUT : layer 7 (HTTP/SMTP)超时时间

      • L6TOUT : layer6(SSL)超时

      • L4TOUT : 1-4层超时

        默认情况下使用L7TOUT。

    • on-success <fmt> : 是可选的 , 如果expect的规则被成功评估并且是tcp-check规则集中的最后一个规则 , 则可用于自定义日志中报告的信息消息。<fmt>是一个日志格式的字符串。

    • on-error <fmt> : 是可选的 , 可用于自定义在expect规则求值期间发生错误时在日志中报告的信息消息。<fmt>是一个日志格式的字符串。

    • <match> : 是一个关键字 , 指示如何在响应。关键字可以是status 、 rstatus、hdr、fhdr , string或rstring。关键字可以在前面加感叹号(!)来取消匹配。空格允许在感叹号和关键字之间。

      默认情况下 , option httpchk认为响应状态为2xx和3xx都是有效的 , 而别人都是无效的。当使用http-check expect时 , 它定义了什么是有效的 , 什么是无效的。只有一个http-check语句在后端中受支持。如果服务器没有响应或超时 , 则检查明显失败。可用的匹配如下:

      • status <codes> : 在解析字符串时发现的状态码。它必须是一个以逗号分隔的状态码或范围码列表。如果响应的状态代码与任何状态代码匹配或在列表的任何范围内 , 则健康检查响应将被视为有效。如果status关键字前缀是! , 那么如果状态码匹配 , 响应将被认为是无效的。

      • restatus <regex> : HTTP状态代码的正则表达式。如果响应的状态码与表达式匹配 , 则健康检查响应将被认为有效。如果"rstatus"关键字前缀是"!" , 那么如果状态码匹配 , 响应将被认为是无效的。这主要用于检查多个代码。

      • hdr { name | name-lf} [-m <meth>] <name>

        [ { value | value-lf } [-m <meth>]] <value>

        在HTTP响应报头上测试指定的报头模式。name模式是强制性的 , 但value模式是可选的。如果未指定 , 则只验证头是否存在。<meth>是匹配方法 , 应用于报头名称或报头值。支持的匹配方法有str(精确匹配) , beg(前缀匹配), end(后缀匹配) , sub(子字符串匹配)或reg(regex匹配)。如果未指定 , 则使用精确匹配方法。如果使用了name-lf参数 ,<name>将被计算为日志格式字符串。如果使用value-lf参数 , <value>将被计算为日志格式字符串。这些参数不能与regex匹配方法一起使用。最后 , 头值被认为是逗号分隔的列表。注意 , header名称的匹配不区分大小写。

      • fhdr { name | name-lf } [ -m <meth> ] <name>

        [ { value | value-lf } [ -m <meth> ] <value> :

        在HTTP响应报头上测试指定的完整报头模式。它所做的与“hdr”关键字完全相同 , 除了测试完整的头值 , 逗号不被视为分隔符。

      • string <string> :在HTTP响应报文中测试准确的字符串匹配。如果响应报文包含此确切字符串 , 则健康检查响应将被视为有效。如果"string"关键字的前缀是"!" , 那么如果响应报文包含这个字符串 , 响应将被认为是无效的。它可以用来在动态页面的末尾查找一个强制词 , 或者在检查页面出现特定错误时检测失败(例如堆栈跟踪)。

      • rstring <regex> : 在HTTP响应报文上测试正则表达式。如果响应报文与此表达式匹配 , 则认为运行状况检查响应有效。如果"rstring"关键字的前缀是"!" , 那么如果响应报文匹配表达式 , 则会被认为是无效的。它可以用来在动态页面的末尾查找一个强制词 , 或者在检查页面出现特定错误时检测失败(例如堆栈跟踪)。

    • <pattern> : 是要查找的模式。它可能是一个字符串 , 一个普通的表达式或带有多个参数的更复杂模式。如果字符串模式包含空格 , 它们必须使用转义通常的反斜杠(\)。

    示例: 

    # only accept status 200 as valid
http-check expect status 200,201,300-310
​
# be sure a sessid coookie is set
http-check expect header name "set-cookie" value -m beg "sessid="
​
# consider SQL errors as errors
http-check expect ! string SQL\ Error
​
# consider status 5xx only as errors
http-check expect ! rstatus ^5
​
# check that we have a correct hexadecimal tag before /html
http-check expect rstring <!--tag:[0-9a-f]*--></html>

  • http-check send :向HTTP运行状况检查期间发送的请求添加头部和/或正文的可能列表。sections :defaults,listen,backend

    http-check send [meth <method>] [{ uri <uri> | uri-lf <fmt> }>] [ver <version>]
                [hdr <name> <fmt>]* [{ body <string> | body-lf <fmt> }]
                [comment <msg>]

    • comment <msg> : 定义了规则求值失败时要报告的消息。

    • meth <emthod> : 可选项, HTTP 请求过程中, 选择一种请求方式。如果没有设置,请求方式默认为OPTIONS。这种通常需要稍微占用服务器进程 , 并且容易从日志中过滤出来。所有的method均可以使用, 到那时不建议使用非标准的方式。

    • uri <uri> : 可选项, 将HTTP请求中引用的URI设置为字符串<URI>。它默认为/ , 这在大部分服务器上默认都是可访问的 , 同样可以更改为任何其他URI。允许查询字符串。

    • ver <version> : 可选项, HTTP版本字符串。它默认为HTTP/1.0 。当HTTP 1.0在一些服务器上出现报错时,可以尝试HTTP/1.1。注意 , Host字段在HTTP/1.1中是必须的 , 使用hdr参数添加它。

    • hdr <name> <fmt> : 添加HTTP header字段, <name>指定对应的头部信息 ； <fmt> : 日志中的显示格式 , 遵循日志格式规则。

    • body <string> : 将<string>定义的正文添加到HTTP健康检查期间发送的请求报文中。如果定义了 , “Content-Length”头就会自动添加到请求中。

    • body-lf <fmt> : 在HTTP 健康检查过程中, 将添加日志格式字符串<fmt>添加到发送的请求正文中。如果定义了 , “Content-Length”头就会自动添加到请求中。

    除了“option httpchk”指令定义的请求行之外 , 这是在HTTP健康检查期间向发送的请求添加一些头和可选的正文的有效方法。如果定义了主体 , 则会自动添加关联的“Content-Length”头。因此 , 这个报头或“Transfer-encoding”报头不应该出现在“http-check send”提供的请求中。如果是这样 , 它将被忽略。以前版本中在“option httpchk”行上的版本字符串后添加头的方式现在已弃用。

    http-send不支持http-alive。请记住 , 它将自动附加一个Connection: close头 , 除非连接头已经通过hdr条目配置。

    注意, 当Host 头部报文与请求权限均被定义时,他们是自动同步。这意味着当Http 请求报文发送时, Host 被插入到请求报文中 , 请求权限也被插入更新。

    目前 , 在HTTP/1.1或以上的请求中 , 没有自动添加主机头。您应该显式地添加它。

5. tcp-check

5.1 option tcp-check

sections :defaults,listen,backend 。

该健康检测方式主要是用为了与后续的tcp-check send/expect命令结合使用。

  • tcp-check目前支持4种操作模式:

    • 没有tcp-check 指令 : 健康检查只包含连接尝试 , 保持默认模式。

    • 只有tcp-check send或tcp-check send-binary : 这是用来发送一个字符串连同一个连接打开。通过一些协议,它可以帮助发送QUIT消息 。 例如防止服务器记录每次健康检查的连接错误。检查结果仍然只基于打开连接的能力。

    • 只有tcp-check expect 指令 : 这是用来测试标题。连接被打开时,HAProxy 等待服务器提供一些必须验证某些规则的内容。检测结果将以内容与检测规则是否匹配为依据。这适用于POP,IMAP,FTP,SSH,TELENT。

    • 同时使用tcp-check send和tcp-check expect。这是用来测试hello类型协议的。

    • HAProxy发送消息 , 服务器响应并分析其响应。检查结果将基于响应内容与规则之间的匹配。这通常适用于需要绑定或request/reponse模型的协议。LDAP, MySQL, Redis和SSL都是这样的协议的例子 , 尽管他们都已经有了他们的专门的检查 , 对各自的协议有了更深的理解。

示例

# perform a POP check (analyze only server's banner)
option tcp-check
tcp-check expect string +OK\ POP3\ ready comment POP\ protocol
​
# perform an IMAP check (analyze only server's banner)
option tcp-check
tcp-check expect string *\ OK\ IMAP4\ ready comment IMAP\ protocol
​
# look for the redis master server after ensuring it speaks well
# redis protocol, then it exits properly.
# (send a command then analyze the response 3 times)
option tcp-check
tcp-check comment PING\ phase
tcp-check send PING\r\n
tcp-check expect string +PONG
tcp-check comment role\ check
tcp-check send info\ replication\r\n
tcp-check expect string role:master
tcp-check comment QUIT\ phase
tcp-check send QUIT\r\n
tcp-check expect string +OK
​
forge a HTTP request, then analyze the response
(send many headers before analyzing)
option tcp-check
tcp-check comment forge\ and\ send\ HTTP\ request
tcp-check send HEAD\ /\ HTTP/1.1\r\n
tcp-check send Host:\ www.mydomain.com\r\n
tcp-check send User-Agent:\ HAProxy\ tcpcheck\r\n
tcp-check send \r\n
tcp-check expect rstring HTTP/1\..\ (2..|3..) comment check\ HTTP\ response

5.2 tcp-check comment

tcp-check comment : 定义以下tcp-check规则的注释 , 如果失败 , 将在日志中报告。

defaults

frontend

listen

backend

yes ✅

no ❌

yes ✅

yes ✅

它只适用于connect、send和expect规则。对用户友好的错误报告是有用的。

5.3 tcp-check connect

tcp-check connect : 开启一个新的连接

tcp-check connect [default] [port <expr>] [addr <ip>] [send-proxy] [via-socks4]
                  [ssl] [sni <sni>] [alpn <alpn>] [linger]
                  [proto <name>] [comment <msg>]

defaults

frontend

listen

backend

yes ✅

no ❌

yes ✅

yes ✅

  • OPTIONS

    • comment : 定义失败之后 , 报告的信息

    • default : 使用服务器行的默认选项执行健康检查。只有在没有重新定义的情况下才使用服务器选项。

    • port <expr> : 检测端口。如果没有设置 , 则使用端口或服务器端口。它告诉HAProxy打开连接到哪里。

    • addr <ip> : 定义进行健康检查的IP地址。

    • ssl : 开启加密连接

    • sni <sni> : 指定特殊的SNI通过SSL 进行健康检测

当一个应用程序位于多个TCP端口上 , 或者当HAProxy在一个后端对多个服务进行负载平衡时 , 在考虑服务器是否可用之前 , 逐个探测所有服务是有意义的。

如果在服务器线路上没有配置TCP端口 , 那么TCP -check connect port <port>必须是该测试步骤中的第一步。

在tcp-check规则集中需要一个connect , 也必须用一个connect规则来启动规则集。目的是确保管理员知道他们在做什么。

示例:

# check HTTP and HTTPs services on a server.
# first open port 80 thanks to server line port directive, then
# tcp-check opens port 443, ciphered and run a request on it:
option tcp-check
tcp-check connect
tcp-check send GET\ /\ HTTP/1.0\r\n
tcp-check send Host:\ haproxy.1wt.eu\r\n
tcp-check send \r\n
tcp-check expect rstring (2..|3..)
tcp-check connect port 443 ssl
tcp-check send GET\ /\ HTTP/1.0\r\n
tcp-check send Host:\ haproxy.1wt.eu\r\n
tcp-check send \r\n
tcp-check expect rstring (2..|3..)
server www 10.0.0.1 check port 80
​
# check both POP and IMAP from a single server:
option tcp-check
tcp-check connect port 110 linger
tcp-check expect string +OK\ POP3\ ready
tcp-check connect port 143
tcp-check expect string *\ OK\ IMAP4\ ready
server mail 10.0.0.1 check

5.4 tcp-check expect

tcp-check expect : 指定在通用健康检查期间要收集和分析的数据

tcp-check expect [min-recv <int>] [comment <msg>]
                 [ok-status <st>] [error-status <st>] [tout-status <st>]
                 [on-success <fmt>] [on-error <fmt>] [status-code <expr>]
                 [!] <match> <pattern>

defaults

frontend

listen

backend

yes ✅

no ❌

yes ✅

yes ✅

  • OPTIONS

    • comment <msg> : 定义了在规则评估失败时要报告的信息。

    • min-recv : 是可选的 , 可以定义评估当前expect规则所需的最小数据量。如果收到的字节数低于这个限制 , 检查将等待更多的数据。这个选项可以用来解决一些模棱两可的匹配规则 , 或者避免在已知仍然不完整的内容上执行昂贵的重码匹配。如果使用一个精确的字符串（字符串或二进制） , 则使用字符串长度和这个参数之间的最小值。如果该参数被设置为-1 , 则被忽略。如果expect规则不匹配 , 检查将等待更多的数据。如果设置为0 , 评估结果即为最终结果。

    • <match> : 是一个关键字 ,表示如何在响应中寻找一个特定的模式。响应中寻找特定的模式。这个关键词可以是 string、rstring、binary或 rbinary。 关键字前面可以加一个感叹号(!)来否定匹配。惊叹号和关键字之间允许有空格。 关键字之间允许有空格。

      • string : 在响应缓冲区中测试准确的字符串匹配。如果响应的缓冲区包含这个确切的字符串 ,则健康检查响应将被认为是有效的。如果string关键字的前缀是! , 那么如果响应体包含这个字符串 , 响应将被认为是无效的。这可以用于在协议响应中查找强制模式 , 或者在协议标题中出现特定错误时检测故障。

      • rstring <regex> : 在响应缓冲区上测试一个正则表达式。如果响应的缓冲区与此表达式相匹配 , 健康检查响应将被视为有效。如果rstring关键字的前缀是! , 那么如果响应体匹配表达式 , 则会被认为是无效的。

      • string-lf <fmt> : 测试响应的缓冲区中的日志格式字符串匹配。如果响应的缓冲区包含<fmt>的评估结果的字符串 , 并遵循日志格式规则 , 则健康检查响应将被视为有效。如果以!为前缀 , 那么如果缓冲区包含该字符串 , 则响应将被视为无效。

      • binary <hexstring> : 测试在响应缓冲区中匹配的十六进制形式的确切字符串。 如果响应的缓冲区有这个确切的十六进制字符串 , 健康检查响应将被视为有效。 目的是为了匹配二进制协议的数据。

      • rbinary <regex> : 在响应缓冲区上测试一个正则表达式 , 像 "rstring"。然而 , 响应缓冲区被转换为十六进制形式 , 包括NUL字节。这允许使用所有的正则引擎来匹配任何二进制内容。 十六进制转换的大小是原始响应的两倍。因此 , 预期的模式最多只能处理一半的响应缓冲区大小。

    • ok-status <st> : 是可选的。如果expect规则被成功评估 , 并且它是的最后一条规则, 可以用来设置检查状态。"L7OK", "L7OKC", "L6OK "和 "L4OK "被支持。

      • L7OK : 第7层的检查通过

      • L7OKC : 在第7层有条件地通过检查 , 将服务器设置为NOLB状态。

      • L6OK : 第6层的检查通过

      • L4OK : 检查在第4层通过

      默认情况下 , 使用L7OK。

    • error-status <st> : 是可选的 , 如果在expect规则评估期间发生错误 ,可以用来设置检查状态。支持 L7OKC、L7RSP、L7STS、L6RSP和 L4CON:

      • L7OKC : 在第7层有条件地通过检查 , 将服务器设置为NOLB状态。

      • L7RSP : 第7层无效响应 , 协议错误

      • L6RSP : 第6层无效响应 , 协议错误

      • L7STS : 第7层响应错误 , 例如HTTP 5xx

      • L4CON : 1-4层连接问题

      默认情况下 , 使用L7RSP。

    • tout-status <st> : 是可选的 , 如果在expect规则评估期间发生超时 ,可以用来设置检查状态。支持 L7TOUT、L6TOUT和 L4TOUT。

      • L7TOUT : 第7层(HTTP/SMTP)超时

      • L6TOUT : 第6层(SSL) 超时

      • L4TOUT : 第1-4层超时

      默认情况下 , 使用 L7TOUT。

    • on-success <fmt> : 是可选的。,如果expect规则被成功评估 , 并且它是tcp-check规则集的最后一条规则, 可以用来定制日志中报告的信息消息。<fmt>是一个日志格式的字符串。

    • on-error <fmt> : 是可选的 , 如果在expect规则评估过程中发生错误 , 可以用来定制在日志中报告的信息消息。<fmt>是一个日志格式的字符串。

    • status-code <expr> : 是可选的 , 可以用来设置日志中报告的检查状态代码(成功或错误时)。<expr>是一个标准的HAProxy表达式 ,由一个样本获取和一些转换器组成。

    • <pattern> : 匹配模式。它可以是一个字符串或一个正则表达式。如果模式包含空格 , 必须用通常的反斜杠（''）来转义。如果匹配被设置为二进制 , 那么模式必须以一系列偶数的十六进制数字的形式传递。每两个数字的序列将代表一个字节。十六进制数字可以使用大写或小写。

需要注意的是 , 响应将被限制在由全局 "tune.bufsize "选项定义的一定大小 , 其默认值为16384字节。 因此 , 在使用 "string"、"rstring "或二进制时 , 太大的响应可能不包含强制模式。 如果绝对需要一个大的响应 , 可以通过设置全局变量来改变默认的最大尺寸。 然而 , 值得注意的是 , 解析非常大的响应会浪费一些CPU周期 , 特别是在使用正则表达式的时候 , 最好是将检查集中在较小的资源上。另外 , 在目前的状态下 , 检查不会发现响应中的任何字符串或正则表达式超过空字符。 同样地 , 也不可能请求匹配空字符。

示例

# perform a POP check
option tcp-check
tcp-check expect string +OK\ POP3\ ready
​
# perform an IMAP check
option tcp-check
tcp-check expect string *\ OK\ IMAP4\ ready
​
# look for the redis master server
option tcp-check
tcp-check send PING\r\n
tcp-check expect string +PONG
tcp-check send info\ replication\r\n
tcp-check expect string role:master
tcp-check send QUIT\r\n
tcp-check expect string +OK

5.5 tcp-check send

tcp-check send <data> [comment <msg>]
tcp-check send-lf <fmt> [comment <msg>]

指定一个字符串或日志格式的字符串 , 作为通用健康检查期间的一个问题来发送

  • comment <msg> : 定义了在规则评估失败时要报告的信息。

  • <data> :将在一般运行状况检查会话期间发送的字符串。

  • <fmt> : 是日志格式字符串 , 一旦被评估 , 将在通用健康检查会话中发送。

# look for the redis master server
option tcp-check
tcp-check send info\ replication\r\n
tcp-check expect string role:master

5.6 tcp-check send-binary

tcp-check send-binary <hexstring> [comment <msg>]
tcp-check send-binary-lf <hexfmt> [comment <msg>]

指定一个十六进制数字字符串或一个十六进制数字的日志格式字符串 , 作为 的二进制问题。

  • comment <msg> : 定义了规则评估失败时要报告的信息。

  • <hexstring> : 是十六进制的字符串 , 一旦转换为二进制 , 将在通用健康检查会话期间发送。

  • <hexfmt> : 是十六进制的日志格式字符串 , 在通用健康检查会话期间 , 一旦被评估并转换为二进制 , 将被发送。

示例

# redis check in binary
option tcp-check
tcp-check send-binary 50494e470d0a # PING\r\n
tcp-check expect binary 2b504F4e47 # +PONG