☰

HAProxy tcp-check expect rstring 未按预期工作

tag-icon • tag-icon haproxy regex
HAProxy tcp-check expect rstring 未按预期工作

我们有一个状态页面，它返回“OK”或“Fail”。我们设置了 tcp-check 来查找“OK”，但不幸的是它不起作用，因为它也匹配“HTTP/1.1 200 OK”。我原本以为我可以使用rstring类似这样的模式.*^OK$。然而，它从不匹配，尽管当我针对此响应测试模式时它有效：

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
X-ServerName: myserver
X-AspNet-Version: 4.0.30319
Date: Wed, 20 Mar 2019 16:23:48 GMT
Content-Length: 2

OK

不像tcp-check expect rstring我想象的那样工作？也许我忽略了一个小细节？这是我在 haproxy 配置中尝试的操作：

这确实不是工作（探测对于 OK 和 Fail 响应均失败）（我正在更改服务器名称和 IP，只是假设它们是有效的）

option tcp-check
tcp-check connect
tcp-check send GET\ /status.ashx\ HTTP/1.0\r\n\r\n
tcp-check expect rstring .*^OK$

server myserver1 1.2.3.4:80 check
server myserver2 1.2.3.5:80 check

以下始终表明两个服务器都在线，无论探测返回 OK 还是 Fail，因为我之前提到的“200 OK”存在问题：

option tcp-check
tcp-check connect
tcp-check send GET\ /offline.txt\ HTTP/1.0\r\n\r\n
tcp-check expect string 404 - File or directory not found.

tcp-check connect
tcp-check send GET\ /status.ashx\ HTTP/1.0\r\n\r\n
tcp-check expect rstring OK

server myserver1 1.2.3.4:80 check
server myserver2 1.2.3.5:80 check

因此简单的“OK”可以与 rstring 一起使用，但是当我尝试应用模式时，它并不按我预期的方式工作。

答案1

经过更多的测试和反复试验，我发现我看到的差异是由于多行正则表达式选项造成的。如果没有设置多行选项，我的模式就不起作用。所以 HAProxy 一定不能使用此选项。顺便说一句，在这种情况下，模式之所以OK$有效，是因为它将其解释为整个字符串以 OK 结尾。如果返回 Fail，则之前以 OK 结尾的行不匹配，因此探测按预期工作。

相关内容