主页 / server / 问题 / 625492
Accepted
Adam C
Asked: 2014-09-02 06:55:28 +0800 CST

如何在 HAProxy 中构建 MongoDB 健康检查？

  • 772

HAProxy 博客上有fastcgi一个二进制运行状况检查的示例。我将如何为 MongoDB 构建一个类似的检查，以便我对其进行更强大的健康检查- 验证服务器是否确实存在并做出响应，而不仅仅是检查端口是否打开？MongoDB

如果健康检查足够通用，可以与各种MongoDB分片组件（配置服务器、、mongos）一起使用，那将很有用mongod。

load-balancing

2 个回答

  1. Best Answer

    首先，值得注意的是，您必须运行 HAProxy 1.5 或更高版本才能使用该tcp-check功能（在撰写此答案时，1.5.3 是当前的稳定版本）。不幸的是，Ubuntu 14.04（例如）附带 1.4 版，因此您需要从其他来源安装。就我个人而言，我使用了这里的软件包，这样我就可以通过apt.

    博客上列出的示例是一个很好的起点。使用它作为模板，我们需要做的就是选择一个适当的命令来运行，然后将该命令分解为十六进制并为 MongoDB 构建适当的检查。MongoDB 有线协议已记录并发布，因此理论上您可以根据规范构建它，但有更简单的方法来解构这样的命令。Wireshark中有内置的解析器，可让您检查 MongoDB 流量，它提供了一个方便的十六进制视图，并突出显示以帮助我们在这里的工作。

    我们将在这里使用的命令是ping 命令。如您所料，它旨在实现轻量级，甚至可以从负载较重的服务器返回，这使其非常适合运行状况检查命令。如果您希望使用其他方法，则可以使用相同的方法编写任何此类命令，但请始终警惕使用需要任何类型的锁定或可能会增加数据库负载的命令。

    为了说明如何从您运行的命令到十六进制，这里是我在 中突出显示的命令的一个小镜头Wireshark，已被解码：

    Wireshark 中的 ping 命令

    基于这些信息，让我们创建我们的TCP健康检查。我将对各个部分进行评论以解释它们的来源，并且每个部分都应该很容易在上面的抓取中找到：

    option tcp-check
 # MongoDB Wire Protocol
 tcp-check send-binary 39000000 # Message Length (57)
 tcp-check send-binary EEEEEEEE # Request ID (random value)
 tcp-check send-binary 00000000 # Response To (nothing)
 tcp-check send-binary d4070000 # OpCode (Query)
 tcp-check send-binary 00000000 # Query Flags
 tcp-check send-binary 746573742e # fullCollectionName (test.$cmd)
 tcp-check send-binary 24636d6400 # continued
 tcp-check send-binary 00000000 # NumToSkip
 tcp-check send-binary FFFFFFFF # NumToReturn
 # Start of Document 
 tcp-check send-binary 13000000 # Document Length (19)
 tcp-check send-binary 01 # Type (Double)
 tcp-check send-binary 70696e6700 # Ping:
 tcp-check send-binary 000000000000f03f # Value : 1
 tcp-check send-binary 00 # Term

 tcp-check expect string ok

    对响应也使用完整的二进制匹配会很好，但不幸的是，无法预测服务器为每个响应生成的请求 ID，因此这样的完整匹配将失败（无法选择性地忽略片段二进制匹配）。

    编辑：2014 年 9 月 8 日感谢Baptiste和Felix的 Q&A 的评论，我回去重新测试最初似乎失败的部分二进制匹配 - 看起来这只是我错误地为响应转录二进制的情况，所以我已经修改了答案以反映这一点。

    “ok”字符串只是一个 OK 检查 - 任何这样的响应都意味着有问题的服务器仍在响应，但有限的检查有点不令人满意。虽然不可能进行完整的响应检查，但请求 ID 之后的所有内容都是可用的。

    因此，这里是对响应的可用部分进行分解的工作二进制检查，再次使用 Wireshark 梳理出上述部分：

    # Check for response (starting after request ID)
tcp-check expect binary EEEEEEEE # Response To (from the check above)
tcp-check expect binary 01000000 # OpCode (Reply)
tcp-check expect binary 00000000 # Reply Flags (none)
tcp-check expect binary 0000000000000000# Cursor ID (0)
tcp-check expect binary 00000000 # Starting From (0)
tcp-check expect binary 11000000 # Document Length (17)
tcp-check expect binary 01 # Type (Double) 
tcp-check expect binary 6f6b # ok
tcp-check expect binary 00000000000000f03f # value: 1
tcp-check expect binary 00 # term

    以上所有内容均已使用 MongoDB 2.6.4 和 HAProxy 1.5.3 成功测试

    • 7

  2. 亚当的答案是正确的，程序也是我使用的。也就是说，不确定响应是否正确，因为服务器也应该回答二进制字符串。亚当，你能确认它适用于你的例子吗？否则，匹配 6f6b 也应该可以解决问题：

    tcp-check 期望二进制 6f6b

    巴蒂斯特

    • 1

相关问题