我有一个三节点ES（elasticsearch）集群前面的haproxy。 到目前为止，我检查haproxy中的每个节点的方式是使用httpcheck。 贝娄是我的configuration的一个片段：
backend elastic_nodes balance roundrobin option forwardfor option httpchk http-check expect status 200 server elastic1 10.88.0.101:9200 check port 9200 fall 3 rise 3 server elastic2 10.88.0.102:9200 check port 9200 fall 3 rise 3 server elastic3 10.88.0.103:9200 check port 9200 fall 3 rise 3 到目前为止，这种检查工作正常，但如果群集变红，响应代码仍然是“200”（这是正确的，因为http-wise节点可访问），这将使haproxy认为后端服务器健康。
另一方面，如果我在收到健康状态“Red”时检查群集的状态并将节点标记为closures，则会将所有后端服务器标记为closures，从而禁用ES服务。 我在这个方法上的问题是，在过去，我的集群实际上是红色的，但它仍然可用，因为只有一个缺less的碎片（一天logging）。 换句话说，在某些情况下，ES Red状态不是一个大问题，而且您仍然想要ES请求（而不是使用haproxy这个阻塞ES服务标记所有的后端节点）。
有没有其他办法呢？
我们使用HAproxy来平衡两个冗余的集群。 在正常操作期间，每个接收约50％的通信量; 在必要时，每个预留100％。
我们最近基于一个我们没有计划的失败案例，经历了一个错误：所有的客户端和主节点都停留了，所以我们的集群响应了REST，但是所有的数据节点都是暂时脱机的，所有的索引都显示为红色和空的，他们返回0结果。 但是，遵循REST惯例200。
在这种情况下，我们简单的HAproxy健康检查失败了; 它只是检查了200多个。
我现在正在调查http-check expect ! string red http-check expect ! string red ，URI直接针对感兴趣的索引。 我以前没有使用更高级的http-checkfunction。
一个更昂贵的检查，但是，应该正确地将lobotomized群集的客户端节点从池中取出。
更新（2）：我已经切换到使用
option httpchk get /_cat/indices/<index of interest> http-check expect rstring \b(green|yellow)\b
这确实是一个更好的testing。
（第二次修订：使用明确的检查green或yellow而不是只是非红色，迟了一会儿索引完全从_cat装… … _