Linux服務器故障怎么排查

本篇內容介紹了“Linux服務器故障怎么排查”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

問題：服務器A無法與服務器B通信

可能大家在實際工作中最常見的網絡故障就是一臺服務器無法與另一臺網絡上的服務器進行通信。本小節將通過實例講解具體處理辦法。在實例中，一臺名為dev1的服務器無法訪問另一臺名為web1的服務器中的網絡服務（端口80）。導致這一現象的原因相當繁雜，因此我們需要一步步測試操作活動，進而通過排除法找到故障的根源。

一般說來，在對這樣的問題進行故障排查時，大家可能會跳過某些初始步驟（例如檢查鏈接等），因為接下來的某些測試環節能起到同樣的診斷作用。舉例來說，如果我們測試并確認DNS能夠正常工作，那么就證明我們的主機是能夠與本地網絡進行通信的。但在本次實例解析中，我們將本著謹慎的態度執行每一個步驟，借以理解各個級別的不同測試方式。

• 問題出在客戶機還是服務器端？

大家可以利用一項快速測試縮小造成故障的范圍，即通過同一網絡中的另一臺主機嘗試訪問對應服務器。在本實例中，我們姑且將另一臺與dev1同處一套網絡環境下的服務器命名為dev2，并嘗試通過它訪問web1。如果dev2也不能正常訪問web1，那么顯然問題很可能出在web1或者是dev1、dev2及web1之間的網絡身上。如果dev2能夠正常訪問web1，那么我們就可以斷定dev1出問題的機率較大。首先，我們假設dev2能夠訪問web1，因此我們開始將故障排查的重點放在dev1這邊。

• 線纜插好了嗎？

故障排查的***步要在客戶機上進行。大家首先要確認自己客戶機的網絡連接沒有問題。要做到這一點，我們可以使用ethtool程序（通過ethtool工具包安裝）對鏈接（即以太網設備與網絡構成物理連接）情況加以檢測。如果大家無法確定自己使用的是哪個端口，那么請運行/sbin/ifconfig命令將所有可用的網絡端口及其設定列出。我們假設自己的以太網設備在eth0端口上，那么：

 $ sudo ethtool eth0
Settings for eth0:
     Supported ports: [ TP ]
     Supported link modes:   10baseT/Half 10baseT/Full 
                               100baseT/Half 100baseT/Full 
                               1000baseT/Half 1000baseT/Full 
     Supports auto-negotiation: Yes
     Advertised link modes:  10baseT/Half 10baseT/Full 
                               100baseT/Half 100baseT/Full 
                               1000baseT/Half 1000baseT/Full 
     Advertised auto-negotiation: Yes
     Speed: 100Mb/s
     Duplex: Full
     Port: Twisted Pair
     PHYAD: 0
     Transceiver: internal
     Auto-negotiation: on
     Supports Wake-on: pg
     Wake-on: d
     Current message level: 0x000000ff (255)
     Link detected: yes

在***一行中，大家可以看到檢測結果顯示鏈接設置為“yes”，所以dev1已經與網絡構成物理連接。如果這項檢測的結果為“no”，那么我們需要親自檢查dev1的網絡連接，并將線纜插實到位。在確定物理連接沒有問題之后，執行下面的步驟。

注意：ethtool絕不僅僅是一款用于檢測鏈接狀況的工具，它還能夠診斷并糾正雙工問題。當Linux服務器與網絡連通時，通常會與網絡自動協商以獲取傳輸速度信息以及該網絡是否支持全雙工。在本實例中，傳輸速度經ethtool檢測為100Mb/秒，且該網絡支持全雙工機制。如果大家發現主機的網絡傳輸速度緩慢，那么速度及雙工設定是首先需要關注的重點。如前文所示運行ethtool，若大家發現雙工被設定為一半，則運行以下命令：

$ sudo ethtool -s eth0 autoneg off duplex full

意思是利用自己的以太網設備代替eth0。

端口正常嗎？

一旦確認了服務器與網絡之間物理連接的完好性，接下來就是判斷主機上的網絡端口是否配置正確。在這方面，***的檢查方式就是運行ifconfig命令并將端口作為參數后綴。因此要測試eth0的設置，大家應該運行以下內容：

$ sudo ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:17:42:1f:18:be  
          inet addr:10.1.1.7  Bcast:10.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::217:42ff:fe1f:18be/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:229 (229.0 B)  TX bytes:2178 (2.1 KB)
          Interrupt:10

在上述輸出結果中，第二行可能最值得我們關注，因為其內容是解釋我們的主機已經被配置了一套IP地址（10.1.1.7）與子網掩碼（255.255.255.0）。現在，大家需要確認這樣的設置結果是否正確。如果端口未受配置，請嘗試運行sudo ifup eth0，然后再次運行ifconfig重新檢查端口是否出現。如果設置錯誤或端口未出現，則檢查/etc/network/interfaces路徑（Debian系統）或/etc/-sysconfig/-network_scripts/ifcfg-<interface>路徑（紅帽系統）。在這些文件中，大家可以修正網絡設置中存在的所有錯誤。現在如果主機通過DHCP獲得自身IP，我們則需要將故障排查轉移到DHCP主機處，找出為什么我們沒有正確獲得IP租用周期。

問題出在本地網絡中嗎？

排除了端口出現的問題之后，接下來我們就該檢查默認網關是否被設置及我們能否對其進行訪問。route命令將顯示出我們當前的路由表，包括默認網關：

$ sudo route -n
Kernel IP routing table
Destination     Gateway      Genmask          Flags Metric Ref     Use Iface
10.1.1.0        *             255.255.255.0    U     0      0        0 eth0
default         10.1.1.1     0.0.0.0           UG    100    0        0 eth0

以上內容中值得關注的在于***一行，也就是default那段內容。在這里，大家可以看到主機網關為10.1.1.1.請注意，由于我們在route命令后添加了-n選項，所以命令不會嘗試將這些IP地址解析為實際主機名稱。這種方式能讓命令的運行更迅速，但更重要的是，我們不希望故障排查工作受到任何潛在DNS錯誤的影響。如果大家沒有在這里看到經過配置的默認網關，而我們想要檢查的主機處于另一子網之下（例如web1為10.1.2.5），那么問題很可能就出在這里。要將其解決，大家一定要確保網關設置要么處于Debian系統的/etc/network/interfaces路徑下、要么是在紅帽系統的/etc/-sysconfig/network_scripts/ifcfg-<interface>路徑下；如果IP是由DHCP所分配，則確保網關在DHCP服務器中被正確設置。在Debian系統中，我們運行如下命令進行端口重置：

$ sudo service networking restart

而在紅帽系統中我們需要運行如下命令進行端口重置：

$ sudo service network restart

請大家注意，即使是如此基本的操作命令在不同的系統發行版中也存在著差異。

一旦確認網關配置完成，我們可以利用ping命令來確認與網關的通信效果：

$ ping -c 5 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=3.13 ms
64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=1.43 ms
64 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=1.79 ms
64 bytes from 10.1.1.1: icmp_seq=5 ttl=64 time=1.50 ms
--- 10.1.1.1 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4020ms
rtt min/avg/max/mdev = 1.436/1.966/3.132/0.686 ms

如大家所見，我們已經能夠正確ping通網關，這至少意味著大家與10.1.1.0網絡能夠進行通信。如果無法ping通網關，那么原因可能分以下幾種。首先，這可能表示我們的網關自動阻斷ICMP數據包。如果是這樣，請告訴網絡管理員阻斷ICMP是種討厭的壞習慣，由此帶來的安全收益也微乎其微。然后嘗試ping同一子網下的另一臺Linux主機。如果ICMP沒有被阻斷，那么可能是主機交換機端口的VLAN設置有誤，所以我們需要進一步檢查接入的交換機。

DNS能正常工作嗎？

一旦確認了與網關之間的通信能力，下面要做的就是測試DNS功能是否正常。nslookup與dig兩款工具都能用于排查DNS方面的問題，但由于在本實例中大家只需要進行一基礎測試，因此我們建議使用nslookup命令可查看服務器能否將web1正確解析為IP地址：

$ nslookup web1
Server: 10.1.1.3
Address: 10.1.1.3#53
Name: web1.example.net
Address: 10.1.2.5

如上所示，實例中的DNS服務器能夠正常工作。web1主機擴展為web1.example.net且被解析為10.1.2.5地址。當然，大家別忘了確認解析出的IP地址與web1應該使用的IP地址相匹配。在本實例中，因為DNS沒有問題，所以我們可以直接跳到下一部分；但有時候DNS也可能出現問題。

沒有配置過的名稱服務器或無法訪問名稱服務器

如果大家看到如下錯誤，這可能意味著要么我們的主機沒有配置過的名稱服務器，要么這些服務器無法進行訪問：

$ nslookup web1
;; connection timed out; no servers could be reached

在這兩種情況下，我們都需要檢查/etc/resolv.conf文件以確認是否存在已配置的名稱服務器。如果我們在這里找不到任何已配置的IP地址，則需要在文件中添加一個名稱服務器。相反，如果我們看到如下所示的內容，則需要通過ping命令對主機與名稱服務器之間的連接進行排查：

search example.net
nameserver 10.1.1.3

如果無法ping通名稱服務器，且其IP地址與我們的主機處于同一子網下（在本實例中，10.1.1.3代表處于同一子網下），則代表名稱服務器本身可能已經崩潰。如果無法ping通名稱服務器且其IP地址與我們的主機處于不同子網下，則直接跳轉至"我能路由至遠程主機嗎？"章節，選擇其中與名稱服務器IP故障排查相關的內容加以執行。如果通過ping通名稱服務器但對方無響應，則跳轉至"遠程端口是否打開？”章節。

缺少搜索路徑或名稱服務器的問題

在運行nslookup命令后，我們還可能得到以下錯誤信息：

$ nslookup web1
Server: 10.1.1.3
Address: 10.1.1.3#53
** server can't find web1: NXDOMAIN

在這里大家可以看到服務器沒有響應，因為它給出的回應表明：服務器無法找到web1。這可能意味著兩種可能性：***，這可能代表web1這一域名并不在DNS搜索路徑當中。這部分搜索設置內容位于/etc/resolv.conf文件當中。推薦一種比較好的測試方式，即執行同樣的nslookup命令，但只使用全稱域名（在本實例中為web1.example.net）。如果能夠被正確解析，則要么在命令中始終使用全稱域名，要么在/etc/resolv.conf中將主機名稱添加到搜索路徑當中（如果大家懶得重復輸入）。

如果連全稱域名也不能奏效，那么問題肯定出在名稱服務器上。這里我們匯總了一些DNS問題的故障排查指南。如果名稱服務器保存有記錄，則需要對其配置進行檢查。如果使用的是遞歸名稱服務器，我們則必須通過查找其它一些域來測試名稱服務器的遞歸機制是否正常。如果其它域都能被正確列出，我們就要看看問題是不是出在包含上述區域的遠程名稱服務器端。

我能路由至遠程主機嗎？

在排除了DNS問題并看到web1被正確解析為IP 10.1.2.5之后，大家需要測試自己能否路由至遠程主機。假如我們的網絡啟用了ICMP，那么最快捷的測試辦法是ping web1。如果該主機能被ping通，我們就知道數據包已經被路由至目的地，這樣的話可以直接跳轉至"遠程端口打開了嗎？"章節。如果無法ping通web1，則嘗試與網絡中的另一臺主機通信看看能否ping通。如果我們無法在遠程網絡中ping通任何主機，就說明數據包無法被正確路由。***的路由問題測試工具這一就是traceroute。一旦與一臺主機建立起路由追蹤，它會測試我們與主機之間的每一次數據包跳轉。舉例來說，dev1與web1之間的一次成功路由追蹤流程將如下所示：

$ traceroute 10.1.2.5
traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets
1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms
2 web1 (10.1.2.5) 8.039 ms 8.348 ms 8.643 ms

這里我們會看到數據包從dev1到達其網關（10.1.1.1），然后再跳轉至web1。這代表著起始位置與目標主機可能都采用10.1.1.1網關。如果大家的操作環境中存在更多路由中轉點，那么顯示的結果可能與上述內容有所不同。如果無法ping通web1，那么輸入結果將如下所示：

$ traceroute 10.1.2.5
traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets
1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms
2 * * *
3 * * *

一旦我們在輸出結果中看到星號，就說明問題出在網關方面。大家需要從路由器著手，看看為什么它無法在兩套網絡之間路由數據包。通過追蹤，大家會看到如下內容：

$ traceroute 10.1.2.5
traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets
1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms
1 10.1.1.1 (10.1.1.1) 3006.477 ms !H 3006.779 ms !H 3007.072 ms

在這種情況下，我們發現ping操作在網關環節出現了超時，這說明該主機可能已經崩潰或無法通過同一子網進行訪問。有鑒于此，如果大家還沒有從同一子網下的其它設備訪問過web1，請嘗試ping及其它測試。

注意：如果某套煩人的網絡仍然在阻斷ICMP，不用擔心，我們仍然有辦法進行路由排查工作。大家只需要安裝tcptraceroute軟件包(sudo apt-get install tcptraceroute)然后運行相同的路由追蹤命令，惟一的區別是用tcptraceroute來代替traceroute 。

遠程端口打開了嗎？

現在我們已經能夠路由至目標設備，但仍然無法在端口80上訪問web服務器。接下來的測試意在檢查端口是否打開。要實現這一目的，我們可以選擇的方案很多。選擇其一，我們可以嘗試telnet：

$ telnet 10.1.2.5 80
Trying 10.1.2.5...
telnet: Unable to connect to remote host: Connection refused

如果大家看到連接被拒絕，那么端口很可能處于關閉狀態（可能是Apache未能運行在遠程主機上或沒有偵聽該端口），也可能是防火墻阻斷了我們的訪問。如果telnet能夠連接，那么恭喜各位，現在大家已經解決了所有網絡問題。但如果web服務的工作狀態與我們的預期不符，則需要檢查web1上的Apache配置（web服務器的故障排查工作在本文的其它章節會談到）。

但相對于telnet，我個人更偏向使用nmap來進行端口測試，因為它往往能夠檢測到防火墻的影響。如果大家還沒有安裝nmap，可以使用軟件包管理器快速安裝nmap軟件包。要對web1進行測試，請輸入以下內容：

$ nmap -p 80 10.1.2.5
Starting Nmap 4.62 ( http://nmap.org ) at 2009-02-05 18:49 PST
Interesting ports on web1 (10.1.2.5):
PORT STATE SERVICE
80/tcp filtered http

nmap果然不負眾望，它一般都能發現所謂"關閉的端口"到底是直接處于關閉狀態、還是在防火墻后處于關閉狀態。通常情況下，nmap會將真正關閉的端口報告為"關閉"，而將防火墻后的端口報告為"過濾"。在我們的測試中它報告其狀態為"過濾"，意味著期間有防火墻作梗并忽略掉了我們的數據包。如此一來，大家就需要檢查網關（10.1.1.1）以及web1上的全部防火墻規則，看看端口80是否處于阻斷狀態。

在本地測試遠程主機

到了這里，擺在我們面前的就有兩種可能性：要么將故障范圍縮小為網絡問題，要么認定毛病出在主機自身。如果大家認定毛病出在主機自身，我們可以通過一系列操作檢查端口80是否可用。

偵聽端口測試

我們在web1上要做的***件事就是測試端口80是否處于偵聽狀態。大家可以使用netstat -lnp命令來列出所有打開且處于偵聽狀態的端口。我們當然可以直接運行這條命令并從輸出結果中篩選出自己想要的結論，但效率更高的方式則是利用grep指定顯示端口80的偵聽狀態：

$ sudo netstat -lnp | grep :80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 919/apache

***列內容顯示出端口所使用的傳輸協議。第二及第三列則顯示接收及發送隊列（這里兩者都被設置為0）。現在我們要注意的是第四列，因為它列出了主機所偵聽的本地地址。此處的0.0.0.0：80告訴我們該主機正偵聽所有端口80流量中與其IP有關的數據。如果Apache只偵聽web1的以太網地址，我們將在輸出結果中看到10.1.2.5：80。

***一列顯示的是哪個進程令端口處于開放狀態。這里我們看到是運行中的Apache正在進行偵聽。如果大家在自己的netstat輸出結果中沒有看到這部分內容，則需要啟動Apache服務器。

防火墻規則

如果進程正在運行且偵聽端口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打理第二個以太網端口（即實例中的eth2），那么請輸入iftop -i eth2。

默認情況下，iftop會試圖將所有IP地址通過解析轉換為主機名稱。這樣做的缺點在于一旦遠程DNS服務器速度緩慢，報告的生成速度也將隨之慘不忍睹。另外，所有DNS解析活動都會增加額外的網絡流量，而這些都會顯示在iftop的報告界面當中。因此要禁用網絡解析功能，別忘了在iftop命令后面加-n哦。

一般說來，iftop顯示的是主機之間所使用的全局帶寬；但為了幫助大家縮小排查范圍，我們可能希望每臺主機具體使用哪個端口進行通信。畢竟只要找到了主機中占用***帶寬的網絡端口，我們就可以在判斷是否接入FTP端口之外進行其它排查手段。啟動iftop之后，按P鍵可以切換端口的顯示與隱藏狀態。不過大家可能會注意到，有時候顯示所有端口狀態可能導致我們正在關注的主機被擠出當前顯示屏幕。如果出現這種情況，我們還可以按S或D鍵來僅顯示來自特定源或特定目標的端口。由于服務項目眾多，目標主機可能隨機使用多個端口并發生帶寬占用峰值，這將導致工具無法識別出正在使用的服務，因此僅顯示源端口還是相當有用的。不過服務器上的端口也可能與當前設備上的服務相對應。在這種情況下，我們可以使用前面提到的netstat -lnp來找出服務所偵聽的端口。

與大多數Linux命令相似，iftop也擁有多種高級選項。我們在文章中提到的這些已經足以涵蓋大多數故障排查需求，但為了滿足大家進一步了解iftop功能的愿望，我教各位一個小技巧：只要輸入man iftop，就可以閱讀包含在軟件包當中的使用手冊、獲得更多與之相關的知識。

“Linux服務器故障怎么排查”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！