如何使用 MTR 诊断网络问题 | HelloDog

标签： | 发表时间：2020-02-26 11:51 | 作者：
出处：https://wsgzao.github.io

前言

MTR 是一款强大的网络诊断工具，网络管理员使用 MTR 可以诊断和隔离网络问题，并且为上游 ISP 提供有用的网络状态报告。MTR 是传统 traceroute 命令的进化版，并且可以提供强大的数据样本，因为他集合了 traceroute 和 ping 这两个命令的精华。本文带您深入了解 MTR ，从数据如何生成，到如果正确理解报告样本并得出相应的结论。

使用 MTR 诊断网络问题

更新历史

2019 年 10 月 23 日 - 增加 iOS 和 Android 客户端的 MTR APP
2019 年 01 月 22 日 - 初稿

阅读原文 - https://wsgzao.github.io/post/mtr/

扩展阅读

MTR - http://www.bitwizard.nl/mtr/
Diagnosing Network Issues with MTR - https://www.linode.com/docs/networking/diagnostics/diagnosing-network-issues-with-mtr/

网络诊断相关的背景知识

Networking diagnostic tools including ping, traceroute, and mtr use Internet Control Message Protocol (ICMP) packets to test contention and traffic between two points on the Internet. When a user pings a host on the Internet, a series of ICMP packets are sent to the host, which responds by sending packets in return. The user’s client is then able to compute the round trip time between two points on the Internet.

In contrast, tools such as traceroute and MTR send ICMP packets with incrementally increasing TTLs in order to view the route or series of hops that the packet makes between the origin and its destination. The TTL, or time to live, controls how many hops a packet will make before “dying” and returning to the host. By sending a series of packets and causing them to return after one hop, then two, then three, MTR is able to assemble the route that traffic takes between hosts on the Internet.

Rather than provide a simple outline of the route that traffic takes across the Internet, MTR collects additional information regarding the state, connection, and responsiveness of the intermediate hosts. Because of this additional information, MTR can provide a complete overview of the connection between two hosts on the Internet. The following sections outline how to install the MTR software and how to interpret the results provided by this tool.

网络诊断工具 例如 ping traceroute mtr 都使用的 “ICMP” 包来测试 Internet 两点之间的网络连接状况。当用户使用 ping 命令 ping 网络上的主机后， ICMP 包将会发送到目的主机，然后在目的主机返回响应。这样，就可以得知本机到目的主机 ICMP 包传输所使用的往返时间。

相对于其他命令仅仅收集传输路径或响应时间，MTR 工具会收集更多的信息，比如 连接状态，连接可用性，以及传输路径中主机的响应性。由于这些额外的信息，我们建议您尽可能完整的展现 Internet 两个主机之间的网络连接信息。接下来我们讲述如何安装 MTR 软件，以及如何看懂这款软件的输出结果。

Diagnostics and Testing - https://www.linode.com/docs/networking/diagnostics/

名词解释

ICMP(Internet Control Message Protocol)
IP 协议族的一员，主要用于网络设备间发送错误指示信息, 一般不用于传输数据，常见部署在用户端网络程序中，诸如 traceroute 或 ping 等程序

TTL(Time To Live)
此处的 Time 表示的是次数，而不是时间，表达的是一个包在结束之前还能经过的跳数

Hop
跳数: 网络中两个端路径上的节点，路由器的数目

ISP(Internet Service Provider)
互联网服务提供商

ping

ping send ICMP ECHO_REQUEST to network hosts

ICMP 是（Internet Control Message Protocol）Internet 控制报文协议。它是 TCP/IP 协议族的一个子协议，用于在 IP 主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。

使用 ping 检查连通性有六个步骤：

  1. 使用 ifconfig 观察本地网络设置是否正确；
  2. ping 127.0.0.1，127.0.0.1 回送地址 Ping 回送地址是为了检查本地的 TCP/IP 协议有没有设置好；
  3. ping 本机 IP 地址，这样是为了检查本机的 IP 地址是否设置有误；
  4. ping 本网网关或本网 IP 地址，这样的是为了检查硬件设备是否有问题，也可以检查本机与本地网络连接是否正常；(在非局域网中这一步骤可以忽略)
  5. ping 本地 DNS 地址，这样做是为了检查 DNS 是否能够将 IP 正确解析。注: /etc/resolv.conf 文件，”nameserver 8.8.8.8” 指定了 dns 服务器的地址，如果启用了 NetworkManager 要注意网卡重启或服务器重启配置被覆盖的问题；
  6. ping 远程 IP 地址，这主要是检查本网或本机与外部的连接是否正常。

安装 MTR

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
11            
12            
13            
14            
15            
16            
17            
18            
19            
20            
21            
22            
23            
24            
25            
26            
27            
28            
29            
30            
31            
32            
33            
34            
35            
36            
37            
38            
39            
40            
41            
42            
43            
44            
45            
46            
47            
48            
# CentOS            
yum install mtr            
# Ubuntu            
apt-get install mtr            
# macOS            
brew install mtr            
# Windows            
BestTrace - https://www.ipip.net/product/client.html            
            
            
Usage:            
mtr [options] hostname            
            
-F, --filename FILEreadhostname(s) from a file            
-4                         use IPv4 only            
-6                         use IPv6 only            
-u, --udp                  use UDP instead of ICMPecho            
-T, --tcp                  use TCP instead of ICMPecho            
-a, --address ADDRESSbindthe outgoing socket to ADDRESS            
-f, --first-ttl NUMBERsetwhat TTL to start            
-m, --max-ttl NUMBER       maximum number of hops            
-U, --max-unknown NUMBER   maximum unknown host            
-P, --port PORT            target port numberforTCP, SCTP, or UDP            
-L, --localport LOCALPORTsourceport numberforUDP            
-s, --psize PACKETSIZEsetthe packet size usedforprobing            
-B, --bitpattern NUMBERsetbit pattern to useinpayload            
-i, --interval SECONDS     ICMPechorequest interval            
-G, --gracetime SECONDS    number of seconds towaitforresponses            
-Q, --tos NUMBERtypeof service fieldinIP header            
-e, --mpls                 display information from ICMP extensions            
-Z, --timeout SECONDS      seconds to keep probe sockets open            
-r, --report               output using report mode            
-w, --report-wide          output wide report            
-c, --report-cycles COUNTsetthe number of pings sent            
-j, --json                 output json            
-x, --xml                  output xml            
-C, --csv                  output comma separated values            
-l, --raw                  output raw format            
-p, --split                split output            
-t, --curses               use curses terminal interface            
--displaymode MODE     select initial display mode            
-n, --no-dnsdonot resove host names            
-b, --show-ips             show IP numbers and host names            
-o, --order FIELDS         select output fields            
-y, --ipinfo NUMBER        select IP informationinoutput            
-z, --aslookup             display AS number            
-h, --helpdisplay thishelpandexit            
-v, --version              output version information andexit

如何读懂 MTR 报告

因为 MTR 报告包括了丰富的信息，新手第一次阅读有点困难。下面是我本地到 google.com 的测试报告

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
11            
12            
13            
14            
15            
[root@sg-gop-10-65-200-186 wangao]# mtr -r google.com            
Start: Wed Jan 23 16:00:30 2019            
HOST: sg-gop-10-65-200-186        Loss%   Snt   Last   Avg  Best  Wrst StDev            
1.|-- 10.65.200.20               0.0%    10    0.3   0.3   0.3   0.5   0.0            
2.|-- ns9.webhostsg.com          0.0%    10    1.0   0.9   0.9   1.0   0.0            
3.|-- 192.168.3.33               0.0%    10    0.9   0.9   0.8   0.9   0.0            
4.|-- vlan242-s4rsm.starhub.net  0.0%    10    1.6   1.8   1.6   1.9   0.0            
5.|-- ancoretl02.starhub.net.sg  0.0%    10    2.0   2.0   1.9   2.1   0.0            
6.|-- anutli12.starhub.net.sg    0.0%    10    1.9   2.1   1.9   3.1   0.3            
7.|-- 72.14.194.0                0.0%    10    2.5   2.7   2.4   4.3   0.5            
8.|-- 74.125.242.35              0.0%    10    2.5   2.5   2.4   2.7   0.0            
9.|-- 216.239.49.74              0.0%    10    3.4   4.4   3.3  12.0   2.6            
10.|-- 74.125.252.254             0.0%    10    3.7   3.7   3.5   3.9   0.0            
11.|-- 108.170.233.49             0.0%    10    4.4   4.2   4.0   4.7   0.0            
12.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

返回结果各列数据说明：

第一列: 显示的是 IP 地址或本机域名，这点和 traceroute 很像

第二列: Loss% 到达此节点的数据包丢包率，显示的每个对应 IP 的丢包率。

第三列: Snt:100 设置发送数据包的数量，默认值是 10 通过参数 -c 来自定义数量。

第四列: Last 显示的最近一次的返回时延

第五列: Avg 平均值这个应该是发送 ping 包的平均时延

第六列: Best 最好或者说时延最低的

第七列: Wrst 最差或者说时延最大的

第八列: StDev 是标准偏差

使用 mtr –report google.com 命令来输出这篇报告。使用 report 选项可以给 google.com 主机发送 10 个 ICMP 包，然后输出报告。如果我们不使用 –report 参数， mtr 会不断的动态运行。在动态模式下， mtr 的输出结果表述每个主机的往返时间。大多数情况下，使用 –report 参数就可以提供足够的数据了。

在命令下面，就是 MTR 产生的输出报告 。在通常情况下， MTR 需要几秒钟的时间来输出报告，但是偶尔可能需要更长的时间。MTR 报告是由一系列跳数组成的（在上述例子中是 12 跳）。“跳” 意味着节点，或路由器，数据包通过它们才能到达目的主机。在上面例子中，数据包经过本地网络的 “内层” 和 “外层”，然后再到一系列的域名主机。主机的域名是通过反向 DNS 查找确定的。如果您想忽略 DNS 查找，您可以使用 –no-dns 参数，使用 –no-dns 参数后，报告结果如下：

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
11            
12            
13            
14            
15            
[root@sg-gop-10-65-200-186 wangao]# mtr -rn google.com            
Start: Wed Jan 23 16:01:02 2019            
HOST: sg-gop-10-65-200-186        Loss%   Snt   Last   Avg  Best  Wrst StDev            
1.|-- 10.65.200.20               0.0%    10    0.2   0.3   0.2   0.3   0.0            
2.|-- 203.117.178.28             0.0%    10    0.8   0.9   0.8   1.1   0.0            
3.|-- 192.168.3.33               0.0%    10    0.8   0.8   0.7   0.9   0.0            
4.|-- 203.117.6.21               0.0%    10    1.8   1.8   1.6   1.9   0.0            
5.|-- 203.118.15.177             0.0%    10    1.8   1.9   1.8   2.1   0.0            
6.|-- 203.118.12.10              0.0%    10    1.9   1.9   1.8   2.1   0.0            
7.|-- 72.14.194.0                0.0%    10    2.4   2.5   2.4   2.7   0.0            
8.|-- 74.125.242.35              0.0%    10    2.6   4.7   2.5  12.6   3.8            
9.|-- 216.239.49.74              0.0%    10    3.5   3.5   3.3   4.0   0.0            
10.|-- 74.125.252.254             0.0%    10    3.7   4.1   3.7   6.6   0.8            
11.|-- 108.170.233.49             0.0%    10    4.3   4.4   4.2   4.7   0.0            
12.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

当我们研究 MTR 报告时候，最好找出每一跳的任何问题。除了可以查看两个服务器之间的路径之外，MTR 在它的七列数据中提供了很多有价值的数据统计报告。 Loss% 列展示了数据包在每一跳的丢失率。 Snt 列记录的多少个数据包被送出。 使用 –report 参数默认会送出 10 个数据包。如果使用 –report-cycles=[number-of-packets] 选项，MTR 就会按照 [number-of-packets] 指定的数量发出 ICMP 数据包。

Last, Avg, Best 和 Wrst 列都标识数据包往返的时间，使用的是毫秒（ ms ）单位表示。 Last 表示最后一个数据包所用的时间， Avg 表示评价时间， Best 和 Wrst 表示最小和最大时间。在大多数情况下，平均时间（ Avg）列需要我们特别注意。

最后一列 StDev 提供了数据包在每个主机的标准偏差。如果标准偏差越高，说明数据包在这个节点的延时越不相同。标准偏差会让您了解到平均延时是否是真的延时时间的中心点，或者测量数据受到某些问题的干扰。

例如，如果标准偏差很大，说明数据包的延迟是不确定的。一些数据包延迟很小（例如：25ms），另一些数据包延迟很大（例如：350ms）。当 10 个数据包全部发出后，得到的平均延迟可能是正常的，但是平均延迟是不能很好的反应实际情况的。如果标准偏差很高，使用最好和最坏的延迟来确定平均延迟是一个较好的方案。

在大多数情况下，您可以把 MTR 的输出分成三大块。根据配置，第二或第三跳一般都是您的本地 ISP，倒数第二或第三跳一般为您目的主机的 ISP。中间的节点是数据包经过的路由器。

分析 MTR 报告

核心的两个参数:

  • loss 丢包率
  • latency 延迟

确定丢包率

当分析 MTR 的输出时，您需要注意两点： loss 和 latency。首先，让我们讨论一下 loss。如果您在任何一跳上看到 loss 的百分比，这就说明这一跳上可能有问题了。当然，很多服务提供商人为限制 ICMP 发送的速率，这也会导致此问题。那么如何才能指定是人为的限制 ICMP 传输还是确定有丢包的现象？我们需要查看下一跳。如果下一跳没有丢包现象，说明上一条是人为限制的。如下示例：

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
root@localhost:~# mtr --report www.google.com            
HOST: example               Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3            
2. 63.247.64.157                50.0%    10    0.4   1.0   0.4   6.1   1.8            
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7            
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1            
5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9            
6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2            
7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3            
8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

在此例中，第二跳发生了丢包现象，但是接下来几条都没任何丢包现象，说明第二跳的丢包是人为限制的。如果在接下来的几条中都有丢包，那就可能是第二跳有问题了。请记住，ICMP 包的速率限制和丢失可能会同时发生。如果发生包的丢失情况，我们要用最低百分比来衡量时间情况。为什么这么说呢？请看如下示例：

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
root@localhost:~# mtr --report www.google.com            
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 63.247.74.43                   0.0%    10    0.3   0.6   0.3   1.2   0.3            
2. 63.247.64.157                  0.0%    10    0.4   1.0   0.4   6.1   1.8            
3. 209.51.130.213                60.0%    10    0.8   2.7   0.8  19.0   5.7            
4. aix.pr1.atl.google.com        60.0%    10    6.7   6.8   6.7   6.9   0.1            
5. 72.14.233.56                  50.0%   10    7.2   8.3   7.1  16.4   2.9            
6. 209.85.254.247                40.0%   10   39.1  39.4  39.1  39.7   0.2            
7. 64.233.174.46                 40.0%   10   39.6  40.4  39.4  46.9   2.3            
8. gw-in-f147.1e100.net          40.0%   10   39.6  40.5  39.5  46.7   2.2

在这个例子中，您可以看打 第 3 跳和第 4 跳都有 60% 的丢包率，从接下来的几跳都有丢包现象，所以不像是人为限制 ICMP 速率的原因。但是最后几跳都是 40% 的丢包率，我们可以猜测到 60% 的丢包率除了网络糟糕的原因之前还有人为限制 ICMP。所以，当我们看到不同的丢包率时，通常要以最后几跳为准。

还有很多时候问题是在数据包返回途中发生的。数据包可以成功的到达目的主机，但是返回过程中遇到 “困难” 了。所以，当问题发生后，我们通常需要收集反方向的 MTR 报告。

此外，互联网设施的维护或短暂的网络拥挤可能会带来短暂的丢包率，当出现短暂的 10% 丢包率时候，不必担心，应用层的程序会弥补这点损失。

读懂网络延迟

除了可以通过 MTR 报告看到丢包率，我们还可以看到本地到目的主机之间的延时。因为不同的物理位置，延迟通常随着跳数的增加而增加。所以，延迟通常取决于节点之间的物理距离和线路质量。

例如，在同样的传输距离下，dial-up 连接比 cable modem 连接有更大的延迟。如下示例中显示 MTR 报告：

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
root@localhost:~# mtr --report www.google.com            
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3            
2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8            
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7            
4. aix.pr1.atl.google.com        0.0%    10  388.0 360.4 342.1 396.7   0.2            
5. 72.14.233.56                  0.0%    10  390.6 360.4 342.1 396.7   0.2            
6. 209.85.254.247                0.0%    10  391.6 360.4 342.1 396.7   0.4            
7. 64.233.174.46                 0.0%    10  391.8 360.4 342.1 396.7   2.1            
8. gw-in-f147.1e100.net          0.0%    10  392.0 360.4 342.1 396.7   1.2

在这份报告中，从第三跳到第四跳的延迟猛增，直接导致了后面的延迟也很大。这可能是因为第四跳的路由器配置不当，或者线路很拥堵的原因。

然而，高延迟并不一定意味着当前路由器有问题。这份报告虽然看到第四跳有点问题，但是数据仍然可以正常达到目的主机并且返回给主机。延迟很大的原因也有可能是在返回过程中引发的。我这份报告我们看不到返回的路径，返回的路径可能是完全不同的线路，所以我们一般要进行双向测试了。

ICMP 速率限制也可能会增加延迟，如下：

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
root@localhost:~# mtr --report www.google.com            
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3            
2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8            
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7            
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1            
5. 72.14.233.56                  0.0%    10  254.2 250.3 230.1 263.4   2.9            
6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2            
7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3            
8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

乍一看，第 4 跳和第 5 跳直接的延迟很大。但是第 5 跳之后，延迟又恢复正常了。最后的延迟差不多为 40ms。像这种情况，是不影响实际情况的。因为可能仅仅是第 5 跳设备限制了 ICMP 传输速率的原因。所以我们一般要用最后一跳的实际延迟为准。

常见的 MTR 报告类型

很多网络问题十分麻烦，并且需要上级网络提供商来帮助。然而，这里有很多常见的 MTR 报告所描述的网络问题。如果您正在经历一些网络问题，并且想诊断出原因，可以参考如下示例：

目的主机网络配置不当

在下面这个例子中，数据包在目的地出现了 100% 的丢包。乍一看是数据包没有到达，其实未必，很有可能是路由器或主机配置不当。

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
[email protected]:~# mtr --report www.google.com            
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3            
2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8            
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7            
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1            
5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9            
6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2            
7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3            
8. gw-in-f147.1e100.net         100.0    10    0.0   0.0   0.0   0.0   0.0

MTR 报告数据包没有到达目的主机是因为目的主机没有发送任何应答。这可能是目的主机防火墙的原因，例如： iptables 配置丢掉 ICMP 包所致。

家庭或办公室路由器的原因

有时候家庭路由器的原因导致 MTR 报告看起来有点误导。

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
11            
12            
13            
% mtr --no-dns --report google.com            
HOST: deleuze                     Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 192.168.1.1                   0.0%    10    2.2   2.2   2.0   2.7   0.2            
2. ???                          100.0    10    8.6  11.0   8.4  17.8   3.0            
3. 68.86.210.126                 0.0%    10    9.1  12.1   8.5  24.3   5.2            
4. 68.86.208.22                  0.0%    10   12.2  15.1  11.7  23.4   4.4            
5. 68.85.192.86                  0.0%    10   17.2  14.8  13.2  17.2   1.3            
6. 68.86.90.25                   0.0%    10   14.2  16.4  14.2  20.3   1.9            
7. 68.86.86.194                  0.0%    10   17.6  16.8  15.5  18.1   0.9            
8. 75.149.230.194                0.0%    10   15.0  20.1  15.0  33.8   5.6            
9. 72.14.238.232                 0.0%    10   15.6  18.7  14.1  32.8   5.9            
10. 209.85.241.148                0.0%    10   16.3  16.9  14.7  21.2   2.2            
11. 66.249.91.104                 0.0%    10   22.2  18.6  14.2  36.0   6.5

不要为 100% 的丢包率所吓到，这并不表明这里有问题。你可以看打在接下来几跳是没有任何丢包的。

运营商的路由器没有正确配置

有时候您的运营商的路由器配置原因，导致 ICMP 包永远不能到达目的地，例如：

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
11            
12            
[email protected]:~# mtr --report www.google.com            
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3            
2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8            
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7            
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1            
5. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0            
6. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0            
7. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0            
8. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0            
9. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0            
10. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0

当没有额外的路由信息时，将会显示问号（???），下面例子也一样：

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
11            
12            
[email protected]:~# mtr --report www.google.com            
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 63.247.74.43                 0.0%    10    0.3   0.6   0.3   1.2   0.3            
2. 63.247.64.157                0.0%    10    0.4   1.0   0.4   6.1   1.8            
3. 209.51.130.213               0.0%    10    0.8   2.7   0.8  19.0   5.7            
4. aix.pr1.atl.google.com       0.0%    10    6.7   6.8   6.7   6.9   0.1            
5. 172.16.29.45                 0.0%    10    0.0   0.0   0.0   0.0   0.0            
6. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0            
7. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0            
8. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0            
9. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0            
10. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0

有时候，一个错误配置的路由器，将会在一个环路中不断发送数据包，如下：

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
11            
12            
13            
14            
15            
16            
[email protected]:~# mtr --report www.google.com            
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3            
2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8            
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7            
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1            
5. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0            
6. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0            
7. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0            
8. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0            
9. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0            
10. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0            
11. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0            
12. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0            
13. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0            
14. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0

通过报告可以看打第 4 跳的路由器没有正确配置。如果这种状况发生了，您可以连接当地的网络管理员或 ISP 解决问题。

ICMP 速率限制

ICMP 速率限制可引起数据包的丢失。如果数据包在这一跳有丢失，但是下面几条都正常，我们可以判断是 ICMP 速率限制的原因。如下：

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
[email protected]:~# mtr --report www.google.com            
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3            
2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8            
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7            
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1            
5. 72.14.233.56                 60.0%    10   27.2  25.3  23.1  26.4   2.9            
6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2            
7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3            
8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

这种状况是没关系的。ICMP 速率限制是一种常见的手段，这样可以减少网络数据的负载，让更重要的流量先通过。

超时

在很多种情况下会发生超时现象。例如：很多路由器可能会直接丢弃 ICMP 包，这时就会导致超时（???）。另外，也有可能在数据返回的路上出现了问题。

1            
2            
3            
4            
5            
6            
7            
8            
9            
10            
[email protected]:~# mtr --report www.google.com            
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev            
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3            
2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8            
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7            
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1            
5. ???                           0.0%    10    7.2   8.3   7.1  16.4   2.9            
6. ???                           0.0%    10   39.1  39.4  39.1  39.7   0.2            
7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3            
8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

超时不一定是数据包被丢失。如上例，数据包还是安全的到达目的地并且返回。中间节点的超时可能是路由器配置丢弃 ICMP 包，或者 QoS 设置引起的原因，这个是没关系的。

MTR 客户端

Windows，macOS，Linux 基本都可以很方便的下载执行 mtr 命令，但 Android 和 iOS 需要安装独立的 APP

MTR 使用小结

  1. mtr 的功能是检查在目的地址有丢包的情况下，查出具体在哪一跳丢包，然后反馈给机房，机房再反馈给运营商；
  2. 看 mtr 的截图，先看最后的目的地址是否有丢包，若最后一跳没有丢包，说明线路 ok，若最后一跳有丢包，往下看；
  3. 再看在路由情况，第一次丢包发生在哪一跳，对应的查这一跳的丢包情况即可；
  4. 如果有条件建议双向测试抓取 mtr 返回结果，对比路由是否对等；
  5. 整理邮件发送机房联系本地网络服务商 ISP 或者云主机服务商请求技术支持。

相关 [mtr 诊断 网络] 推荐：

如何使用 MTR 诊断网络问题 | HelloDog

- -
MTR 是一款强大的网络诊断工具，网络管理员使用 MTR 可以诊断和隔离网络问题，并且为上游 ISP 提供有用的网络状态报告. MTR 是传统 traceroute 命令的进化版，并且可以提供强大的数据样本，因为他集合了 traceroute 和 ping 这两个命令的精华. 本文带您深入了解 MTR ，从数据如何生成，到如果正确理解报告样本并得出相应的结论.

如何诊断CDN故障

- - 火丁笔记
某项目使用CDN做文件下载服务，最近不时有网友反馈下载出错，因为CDN是第三方提供的，且节点众多，所以诊断起来有点麻烦，必须想想招儿. 首当其冲的问题是如何确认CDN有哪些节点. 幸运的是通过 阿里测提供的服务，我们能拿到这个IP列表，当然这个IP列表不可能百分百完整，不过应该包含了大部分的节点，有兴趣的可以参考 百度的JQuery CDN例子.

JVM诊断调优CheatSheet

- - ImportNew
使用top去获取进程cpu使用率；使用/proc文件查看进程所占内存. 查看类的一些信息，如字节码的版本号、常量池等. 查看进程的gc情况. jstat -gcutil [pid] (显示总体情况). jstat -gc [pid] 1000 10（每隔1秒刷新一次 一共10次）. 查看jvm内存使用状况.

初步诊断你的 GC

- - IT瘾-dev
本文是好友阿飞写的，并且经过作者同意发的原创. 阿飞Javaer，转载请注明原创出处，谢谢. JVM的GC机制让Java程序员省去了自己垃圾回收的烦恼，大大提高了生产效率. 但是正因为JVM垃圾回收机制足够优秀，导致很多Java程序员对JVM这个黑盒了解甚少，很多人没有去了解它，很多人也没机会去了解它.

使用pt-stalk诊断MySQL问题

- - haohtml's blog
在MySQL服务器出现短暂(5~30秒)的性能波动的时候，一般的性能监控工具都很难抓住故障现场，也就很难收集对应较细粒度的诊断信息. 另外，如果这种波动出现的频率很低，例如几天才一次，我们也很难人为的抓住现场，收集数据. 这正是pt-stalk所解决的问题. pt-stalk是 Percona-Toolkit的一部分(其前身是 Aspersa的一部分).

网站诊断之建议篇

- - Google 黑板报 - Google （谷歌）中国的博客网志，走近我们的产品、技术和文化
发表者：谷歌中文搜索质量团队. 转载自： 谷歌中文网站管理员博客. 发布时间：2012年1月18日 上午 10:46:00. 几周之前，我们曾邀请非营利性的公益网站站长向我们的搜索质量团队提交他们的网站，参加我们的在线网站诊断活动. 感谢积极参加此次活动的公益网站站长. 现在我们根据提交的网站，总结出了一些需要改进的地方，并提供了一些建议以及您可以从谷歌获得的资源.

使用pt-stalk诊断MySQL问题

- - OurMySQL
在MySQL服务器出现短暂(5~30秒)的性能波动的时候，一般的性能监控工具都很难抓住故障现场，也就很难收集对应较细粒度的诊断信息. 另外，如果这种波动出现的频率很低，例如几天才一次，我们也很难人为的抓住现场，收集数据. 这正是pt-stalk所解决的问题. pt-stalk是 Percona-Toolkit的一部分(其前身是 Aspersa的一部分).

ThreadSafe:诊断并发问题的利器

- - Java译站
听到ThreadSafe这个东西我的第一反应就是， ”天啊，又出了一个静态代码分析工具”. 在内部开发中引入了像PMD或者FindBugs这类的工具，又花了不少时间优化成零警告后，我感觉已经不再需要其它的工具了. ThreadSafe这个工具跟别的代码分析工具一样，但有一点不同，它更专注于Java开发中一个非常重要的领域——并发.

诊断Java中的内存泄露

- - ImportNew
每次我怀疑有内存泄漏时，我都要翻箱倒柜找这些命令. 首先，我用下面的命令监视进程：. （如果有的话还有New Relic）. 如果你看到内存上升很快，可能是因为虚拟机设置. 如果你没有明确指定JVM的内存设置，它将设置默认值给他们. 如果这些都不符合你所希望的，那么你就需要指定JVM的内存设置. 可以用下面的命令设置最小和最大堆大小：.

.Net Core 全局性能诊断工具

- - IT瘾-dev
现在.NET Core 上线后，不可避免的会出现各种问题，如内存泄漏、CPU占用高、接口处理耗时较长等问题. 这个时候就需要快速准确的定位问题，并解决. 这时候就可以使用.NET Core 为开发人员提供了一系列功能强大的诊断工具. 接下来就详细了解下：.NET Core 全局诊断工具. dotnet-counters 是一个性能监视工具，用于初级运行状况监视和性能调查.