使用 MTR 诊断因果集群中的网络延迟
MTR 是一种基于 ICMP 的简单测试，结合了 ping 和 traceroute。下面演示了使用 MTR 跟踪工具来诊断因果集群中的网络延迟和数据包丢失。该工具通常在 Windows 上通过 WinMTR（https://sourceforge.net/projects/winmtr/）使用，但本文描述了在 Unix 终端上的示例用法。本文不涉及安装及各种使用选项，相关参考可见文末的 Linode 网站。
OSX 安装
$ brew install mtr这应当允许使用 sudo /usr/local/sbin/mtr 执行，但执行下面的两条命令可以简化为 sudo mtr
$ sudo ln /usr/local/Cellar/mtr/0.92/sbin/mtr /usr/local/bin/mtr
$ sudo ln /usr/local/Cellar/mtr/0.92/sbin/mtr-packet /usr/local/bin/mtr-packet使用 MacPorts 安装，请运行
$ port install mtr参数
| 用法 | 详细模式 | 描述 |
|---|---|---|
-F |
--filename FILE |
从文件读取主机名（可多个） |
-4 |
仅使用 IPv4 |
|
-6 |
仅使用 IPv6 |
|
-u |
--udp |
使用 UDP 而非 ICMP 回显 |
-T |
--tcp |
使用 TCP 而非 ICMP 回显 |
-a |
--address ADDRESS |
将出站套接字绑定到 ADDRESS |
-f |
--first-ttl NUMBER |
设置起始的 TTL 值 |
-m |
--max-ttl NUMBER |
最大跳数 |
-U |
--max-unknown NUMBER |
最大未知主机数 |
-P |
--port PORT |
TCP、SCTP 或 UDP 的目标端口号 |
-L |
--localport LOCALPORT |
UDP 的源端口号 |
-s |
--psize PACKETSIZE |
设置探测使用的数据包大小 |
-B |
--bitpattern NUMBER |
设置负载中的位模式 |
-i |
--interval SECONDS |
ICMP 回显请求的间隔（秒） |
-G |
--gracetime SECONDS |
等待响应的秒数 |
-Q |
--tos NUMBER |
IP 首部中的服务类型字段 |
-e |
--mpls |
显示 ICMP 扩展信息 |
-Z |
--timeout SECONDS |
探测套接字保持打开的秒数 |
-r |
--report |
以报告模式输出 |
-w |
--report-wide |
输出宽幅报告 |
-c |
--report-cycles COUNT |
设置发送的 ping 次数 |
-j |
--json |
输出 JSON |
-x |
--xml |
输出 XML |
-C |
--csv |
输出逗号分隔值 |
-l |
--raw |
输出原始格式 |
-p |
--split |
拆分输出 |
-t |
--curses |
使用 curses 终端界面 |
--displaymode MODE |
选择初始显示模式 |
|
-n |
--no-dns |
不解析主机名 |
-b |
--show-ips |
显示 IP 地址和主机名 |
-o |
--order FIELDS |
选择输出字段 |
-y |
--ipinfo NUMBER |
选择输出中的 IP 信息 |
-z |
--aslookup |
显示自治系统 (AS) 编号 |
-h |
--help |
显示帮助信息并退出 |
-v |
--version |
输出版本信息并退出 |
以下示例仅描述在 OSX 上的使用方法，但在其他操作系统上的用法非常相似。
用法
sudo mtr <destination domain name or ip>
如果需要摘要而不是实时响应更新，请执行以下命令
sudo mtr -rwn -i 2 -c 5 <domain name or ip> > /User/<username>/Desktop/mtr.txt 其中 i 表示 ping 间隔（秒），此处为 2。该命令将追踪报告输出到上述路径下的 mtr.txt 文件。
运行 mtr -P <tcp port> -T -w <destination ip> 生成报告。默认情况下会向目标发送 10 个数据包。Loss% 列显示每一跳的丢包百分比，Snt 列计数已发送的数据包数。
接下来的四列 Last、Avg、Best 与 Wrst 均为毫秒级的延迟测量。Last 为最近一次发送的数据包的延迟，Avg 为所有数据包的平均延迟，Best 与 Wrst 分别显示到该主机的最短（最佳）和最长（最差）往返时间。大多数情况下应关注 Avg（平均）列。最后的 StDev 列提供每个主机延迟的标准偏差，数值越大说明延迟波动越大。
分析 MTR 输出时，关注两点：丢包和延迟。下面展示了执行 mtr -P 80 -T -w <ip> 的测试结果示例。
当没有额外路由信息时会显示 ???。在上例中，第 9 到第 16 跳几乎没有信息可用。当不同跳之间出现可变丢包时，建议信任后面跳的响应时间。
在上述示例中，第 6 跳到第 7 跳出现 20% 丢包，第 7 跳到第 8 跳出现 80% 丢包，目标本身也有 80% 丢包。这可能导致高延迟（数十秒），且问题主要出在第 6、7、8 跳。请注意部分丢包可能是速率限制导致的。如果目标没有丢包，说明连通性良好。此例的平均延迟为 86.4 ms，第 8‑16 跳大约增加了 100 ms 的延迟。
能够指定源地址和端口，使该工具在测试集群内部延迟时尤其有用。用户可以指定源地址、端口以及使用的协议（如 UDP 或 TCP）来代替 ICMP。
例如，如果在 Neo4j 服务器端设置 dbms.connector.bolt.listen_address=:7688，可以通过在服务器上执行 MTR 跟踪来测试网络延迟对查询响应时间的影响，例如：sudo mtr -rwn -i 2 -c 5 -P 7688 -T <client IP 或另一个集群成员 IP>。
对于一个包含 3 个核心的因果集群，假设其 bolt 监听地址分别为 dbms.connector.bolt.listen_address=:7688、dbms.connector.bolt.listen_address=:7689 与 dbms.connector.bolt.listen_address=:7690，我们可以测试实例 1（源）到实例 2（目标）之间的内部延迟，例如：sudo mtr -c 5 -T -P 7689 192.168.8.103
此页面有帮助吗？