使用 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 <域名或 IP> > /User/<用户名>/Desktop/mtr.txt，其中 i 是 ping 间隔（以秒为单位），在本例中为 2。这会将跟踪报告输出到上述指定位置的 mtr.txt 文件。
运行 mtr -P <tcp 端口> -T -w <目标 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% 的数据包丢失。这可能导致高延迟（10 秒），在本例中，似乎归因于跃点 6、7 和 8。请注意，一些数据包丢失是由于速率限制造成的。如果目标上没有数据包丢失，则表示连接良好。请注意上面延迟的平均值为 86.4 毫秒。在本例中，跃点 8 到 16 似乎引入了大约 100 毫秒的延迟。
能够指定源地址和端口使此工具特别适用于测试集群内延迟。可以指定源地址和端口，以及使用 UDP 或 TCP 等协议代替 ICMP。
例如，如果在 neo4j 服务器端设置了 dbms.connector.bolt.listen_address=:7688，则可能需要测试将添加到查询响应时间的网络延迟，方法是执行从服务器到客户端的 MTR 跟踪，例如 sudo mtr -rwn -i 2 -c 5 -P 7688 -T <客户端的 IP 或另一个集群成员的 IP>。
对于具有 dbms.connector.bolt.listen_address=:7688、dbms.connector.bolt.listen_address=:7689 和 dbms.connector.bolt.listen_address=:7690 的示例 3 核因果集群，我们可以测试实例 1（源）和 2（目标）之间的集群内延迟，例如 sudo mtr -c 5 -T -P 7689 192.168.8.103
此页面是否有帮助？