|
防火墙规则 如果进程正在运行且侦听端口80，那就说明可能是web1中某种形式的防火墙导致了问题的发生。利用iptables命令列出全部现有防火墙规则。如果我们的防火墙已被禁用，那么输出结果应如下所示： $ sudo /sbin/iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination 请注意，默认政策被设置为ACCEPT。尽管规则本身没有问题，但防火墙仍然有可能默认弃用所有数据包。如果属于这类情况，大家会看到如下所示的输出内容： $ sudo /sbin/iptables -L Chain INPUT (policy DROP) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination 另一方面，如果某条防火墙规则阻断了端口80，那么输出结果则应如下所示： $ sudo /sbin/iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 reject-with( icmp-port-unreachable Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination 在后一种情况下，我们显然需要修改防火墙规则，以允许服务器接收来自端口80的主机数据流量。 网络缓慢状况的故障排查 从某种角度来说，网络无法工作的问题更容易解决。当一台主机无法访问，我们可以执行前面讨论过的故障排查步骤直到一切恢复正常。但如果仅仅是网络缓慢，追查其根本原因往往变得更为棘手。本章节将讨论一些相关技巧，帮助大家追踪导致网络速度缓慢的各种原因。 DNS问题 虽然DNS在网络出现问题时常常蒙冤受责，但在导致网络性能不佳方面，DNS倒真该被优先检查一番。举例来说，如果我们为某个域名配置了两台DNS服务器，那么在第一台出现问题时，我们发出的DNS请求会等待30秒之后才传输至第二台DNS服务器。虽然当我们使用像dig或nslookup这样的工具时此类情况显得一目了然，但对于日常使用来说，DNS故障往往会以令人意外的方式造成网络缓慢；这是因为有太多服务需要借助DNS实现将主机名称解析为IP地址的工作。这些问题甚至有可能影响到我们的网络故障诊断工具。 Ping、tracerouter、oute、netstat甚至包括iptables在内的多款网络故障排查工具都会受到DNS问题的牵连而导致速度缓慢。在默认情况下，上述所有工具都会尽可能尝试将IP地址解析为主机名称。一旦DNS服务器有了毛病，这些命令就会在查找IP地址的过程中停滞不前并最终导致执行失效。在ping或traceroute方面，问题表现为整个ping应答周期耗时相当长，但最终的请求往返时间却比较短。而在netstat与iptables方面，其请求结果可能会拖延很久才输出到屏幕上，这是因为系统一直在等待已经超时的DNS请求。 在前面提到的各种情况中，我们都能很容易地绕过DNS来保证故障排查结果的准确性。所有列举的命令都可以通过添加-n参数来禁止其将IP地址解析为主机名称。我也是刚刚养成在所有命令后加-n的好习惯--正如第一章提到的那样--除非我确定自己想解析IP地址。 注意：DNS解析还可能以其它一些意想不到的方式影响我们的web服务器性能。某些web服务器会根据配置对访问的第一个IP地址进行解析，并将得到的主机名称记录下来。虽然这会让记录信息更具可读性，但同时也会在出现问题时大大降低web服务器的速度--例如存在大量访问者时。这时web服务器会忙着解决这些IP地址的解析工作，而选择将服务流量搁置在一边。 利用traceroute解决网络缓慢问题 当处于不同网络中的服务器与主机间的连接发生拖慢状况时，我们可能很难追查到真正的罪魁祸首。尤其是在拖慢以延迟形式（即响应所消耗的时间）出现而不涉及全局带宽的情况下，真正能力挽狂澜的就只有traceroute了。正如前文所说，tracerout是一种在远程网络中测试客户机与服务器间全局连接的有效方式，但它同时也能有效诊断出导致网络缓慢的潜在根源。由于traceroute会输出当前与目标设备之间每次数据转发所消耗的时间，因此我们可以利用它追踪由地域相距过大或网关问题所引发的过载及网络缓慢原因。举例来说，我们利用traceroute检查美国与中国两边的雅虎服务器，输出结果如下所示： $ traceroute yahoo.cn traceroute to yahoo.cn (202.165.102.205), 30 hops max, 60 byte packets 1 64-142-56-169.static.sonic.net (64.142.56.169) 1.666 ms 2.351 ms 3.038 ms 2 2.ge-1-1-0.gw.sr.sonic.net (209.204.191.36) 1.241 ms 1.243 ms 1.229 ms 3 265.ge-7-1-0.gw.pao1.sonic.net (64.142.0.198) 3.388 ms 3.612 ms 3.592 ms 4 xe-1-0-6.ar1.pao1.us.nlayer.net (69.22.130.85) 6.464 ms 6.607 ms 6.642 ms 5 ae0-80g.cr1.pao1.us.nlayer.net (69.22.153.18) 3.320 ms 3.404 ms 3.496 ms 6 ae1-50g.cr1.sjc1.us.nlayer.net (69.22.143.165) 4.335 ms 3.955 ms 3.957 ms 7 ae1-40g.ar2.sjc1.us.nlayer.net (69.22.143.118) 8.748 ms 5.500 ms 7.657 ms 8 as4837.xe-4-0-2.ar2.sjc1.us.nlayer.net (69.22.153.146) 3.864 ms 3.863 ms 3.865 ms 9 219.158.30.177 (219.158.30.177) 275.648 ms 275.702 ms 275.687 ms 10 219.158.97.117 (219.158.97.117) 284.506 ms 284.552 ms 262.416 ms 11 219.158.97.93 (219.158.97.93) 263.538 ms 270.178 ms 270.121 ms 12 219.158.4.65 (219.158.4.65) 303.441 ms * 303.465 ms 13 202.96.12.190 (202.96.12.190) 306.968 ms 306.971 ms 307.052 ms 14 61.148.143.10 (61.148.143.10) 295.916 ms 295.780 ms 295.860 ms ... 既然不了解有关网络的更多细节信息，我们也能够单纯通过往返时间把握数据包的动向。从第九次跳转开始，IP地址变成了219.158.30.177，这意味着数据包已经离开美国抵达中国，而跳转的往返时间也从3毫秒提高到275毫秒。 利用iftop找出是谁占用了带宽 有时候我们的网络缓慢并不是由远程服务器或路由器所引起，而只是因为系统中的某些进程占用了太多可用带宽。虽然从直观角度我们很难确定哪些进程正在使用带宽，但也有一些工具能帮大家把这些捣蛋的家伙揪出来。 top就是这样一款出色的故障排查工具，它的出现还带来一系列思路相似的衍生品，例如iotop--能够确定到底是哪些进程占用了大部分磁盘I/O性能。最终名为iftop的工具横空出世，能够在网络连接领域提供同等功能。与top不同，iftop不会亲自关注进程情况，而是列出用户服务器与远程IP之间占用带宽最多的连接对象。举例来说，我们可以在iftop中快速查看备份服务器IP地址在输出结果中的位置来判断备份工作有没有大量占用网络带宽。
iftop输出图示 红帽与Debian的各个发行版都能使用iftop这一名称的软件包，但在红帽发行版方面大家可能需要从第三方资源库才能获取。一旦安装过程完成，我们在命令行中运行iftop命令即可启用（需要root权限）。和top命令一样，我们可以点Q键退出。 在iftop界面屏幕的最上方是显示全局流量的信息栏。信息栏之下则是另外两列信息，一列为源IP、另一列为目标IP，二者之间以箭头填充帮助我们了解带宽被用于从自己的主机向外发送数据还是从远程主机端接收数据。再往下则是另外三个栏位，表示两台主机之间在2秒、10秒及40秒中的数据传输速率。与平均负载相似，大家可以看到目前带宽使用是否达到峰值，或者在过去的哪个时段达到过峰值。在屏幕的最下方，我们会找到传输数据（简称TX）与接收数据（简称RX）的总体统计结果。与top差不多，iftop的界面也会定期更新。 在不添加额外参数的情况下，iftop命令通常能够满足我们故障排查的全部需求；但有的时候，我们可能也希望利用一些选项实现特殊功能.iftop命令在默认情况下会显示查找到的第一个端口的统计信息，但在某些服务器中大家可能会使用多个端口，所以如果我们希望让iftop打理第二个以太网端口（即实例中的eth1），那么请输入iftop -i eth1。 默认情况下，iftop会试图将所有IP地址通过解析转换为主机名称。这样做的缺点在于一旦远程DNS服务器速度缓慢，报告的生成速度也将随之惨不忍睹。另外，所有DNS解析活动都会增加额外的网络流量，而这些都会显示在iftop的报告界面当中。因此要禁用网络解析功能，别忘了在iftop命令后面加-n哦。 一般说来，iftop显示的是主机之间所使用的全局带宽；但为了帮助大家缩小排查范围，我们可能希望每台主机具体使用哪个端口进行通信。毕竟只要找到了主机中占用最大带宽的网络端口，我们就可以在判断是否接入FTP端口之外进行其它排查手段。启动iftop之后，按P键可以切换端口的显示与隐藏状态。不过大家可能会注意到，有时候显示所有端口状态可能导致我们正在关注的主机被挤出当前显示屏幕。如果出现这种情况，我们还可以按S或D键来仅显示来自特定源或特定目标的端口。由于服务项目众多，目标主机可能随机使用多个端口并发生带宽占用峰值，这将导致工具无法识别出正在使用的服务，因此仅显示源端口还是相当有用的。不过服务器上的端口也可能与当前设备上的服务相对应。在这种情况下，我们可以使用前面提到的netstat -lnp来找出服务所侦听的端口。 与大多数Linux命令相似，iftop也拥有多种高级选项。我们在文章中提到的这些已经足以涵盖大多数故障排查需求，但为了满足大家进一步了解iftop功能的愿望，我教各位一个小技巧：只要输入man iftop，就可以阅读包含在软件包当中的使用手册、获得更多与之相关的知识。 原文链接：http://www.computerworld.com/s/article/9236224/Server_s_down_How_do_I_find_out_what_s_wrong_?taxonomyId=89 译文：http://server.51cto.com/sCollege-386358.htm (责任编辑：IT) |
