Haproxy “原因：第6层超时”可能是什么意思？

我有一个haproxy，在后端配置了两台服务器。偶尔，每16-20小时，其中一个会被haproxy标记为DOWN：

haproxy.log-20190731:2019-07-30T16:16:24+00:00 <local2.alert> haproxy[2716]: Server be_kibana_elastic/kibana8 is DOWN, reason: Layer6 timeout, check duration: 2000ms. 0 active and 0 backup servers left. 8 sessions active, 0 requeued, 0 remaining in queue.

---

第6层是指TLS。后端正在接受TCP连接，但未在允许的时间内协商健康检查连接上的TLS SSL

配置值timeout connect、timeout check和inter都相互作用，以确定允许完成多少时间的运行状况检查，如果未指定，inter的默认值为2000毫秒，这就是您在这里看到的。默认情况下，运行状况检查间隔决定检查运行的频率和允许检查完成的时间

由于您尚未为服务器配置下降计数，这意味着正在使用默认值3，这意味着您的服务器在被标记之前实际上连续3次未通过运行状况检查

考虑将选项日志运行状况检查添加到后端声明中，这将在最后一项导致后端被标记之前，为那些初始失败的检查创建额外的日志条目

增加允许的时间可以避免失败，但可能仅对测试有效-而不是修复-因为如果后端无法在2000毫秒内可靠地响应检查，那么它也无法在该时间范围内可靠地响应客户端连接，这需要很长时间来等待响应

请注意，在典型环境中，间歇性数据包丢失通常会导致3000毫秒的延迟行为，因为TCP堆栈通常使用3秒的重传超时RTO。由于这超过2000毫秒，网络上的数据包丢失可能是问题的一种解释

---

另一种可能的解释是后端CPU负载过大，这可能与通信量有关，也可能与cron作业的强度有关，因为从CPU的角度来看，TLS协商相对来说是一个昂贵的过程。

谢谢！您认为后端服务器不响应SSL协商的原因可能是什么？我在答案中添加了一些可能有用的附加信息。非常好，谢谢！你是一个真实的人，不是一个机器人，对吗？尽管回答一个暗示我是机器人的答案很诱人，但我是一个真实的人。这个名字的灵感来源于我担任DBA的那段日子。

backend be_kibana_elastic
    balance roundrobin
    stick   on src
    stick-table  type ip size 100k expire 12h
    server kibana8 172.24.0.1:5601 check ssl verify none
    server kibana9 172.24.0.2:5601 check ssl verify none