Linux服務(wù)器故障怎么排查

本篇內(nèi)容介紹了“Linux服務(wù)器故障怎么排查”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

問(wèn)題：服務(wù)器A無(wú)法與服務(wù)器B通信

可能大家在實(shí)際工作中最常見(jiàn)的網(wǎng)絡(luò)故障就是一臺(tái)服務(wù)器無(wú)法與另一臺(tái)網(wǎng)絡(luò)上的服務(wù)器進(jìn)行通信。本小節(jié)將通過(guò)實(shí)例講解具體處理辦法。在實(shí)例中，一臺(tái)名為dev1的服務(wù)器無(wú)法訪問(wèn)另一臺(tái)名為web1的服務(wù)器中的網(wǎng)絡(luò)服務(wù)（端口80）。導(dǎo)致這一現(xiàn)象的原因相當(dāng)繁雜，因此我們需要一步步測(cè)試操作活動(dòng)，進(jìn)而通過(guò)排除法找到故障的根源。

一般說(shuō)來(lái)，在對(duì)這樣的問(wèn)題進(jìn)行故障排查時(shí)，大家可能會(huì)跳過(guò)某些初始步驟（例如檢查鏈接等），因?yàn)榻酉聛?lái)的某些測(cè)試環(huán)節(jié)能起到同樣的診斷作用。舉例來(lái)說(shuō)，如果我們測(cè)試并確認(rèn)DNS能夠正常工作，那么就證明我們的主機(jī)是能夠與本地網(wǎng)絡(luò)進(jìn)行通信的。但在本次實(shí)例解析中，我們將本著謹(jǐn)慎的態(tài)度執(zhí)行每一個(gè)步驟，借以理解各個(gè)級(jí)別的不同測(cè)試方式。

• 問(wèn)題出在客戶機(jī)還是服務(wù)器端？

大家可以利用一項(xiàng)快速測(cè)試縮小造成故障的范圍，即通過(guò)同一網(wǎng)絡(luò)中的另一臺(tái)主機(jī)嘗試訪問(wèn)對(duì)應(yīng)服務(wù)器。在本實(shí)例中，我們姑且將另一臺(tái)與dev1同處一套網(wǎng)絡(luò)環(huán)境下的服務(wù)器命名為dev2，并嘗試通過(guò)它訪問(wèn)web1。如果dev2也不能正常訪問(wèn)web1，那么顯然問(wèn)題很可能出在web1或者是dev1、dev2及web1之間的網(wǎng)絡(luò)身上。如果dev2能夠正常訪問(wèn)web1，那么我們就可以斷定dev1出問(wèn)題的機(jī)率較大。首先，我們假設(shè)dev2能夠訪問(wèn)web1，因此我們開(kāi)始將故障排查的重點(diǎn)放在dev1這邊。

• 線纜插好了嗎？

故障排查的***步要在客戶機(jī)上進(jìn)行。大家首先要確認(rèn)自己客戶機(jī)的網(wǎng)絡(luò)連接沒(méi)有問(wèn)題。要做到這一點(diǎn)，我們可以使用ethtool程序（通過(guò)ethtool工具包安裝）對(duì)鏈接（即以太網(wǎng)設(shè)備與網(wǎng)絡(luò)構(gòu)成物理連接）情況加以檢測(cè)。如果大家無(wú)法確定自己使用的是哪個(gè)端口，那么請(qǐng)運(yùn)行/sbin/ifconfig命令將所有可用的網(wǎng)絡(luò)端口及其設(shè)定列出。我們假設(shè)自己的以太網(wǎng)設(shè)備在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

在***一行中，大家可以看到檢測(cè)結(jié)果顯示鏈接設(shè)置為“yes”，所以dev1已經(jīng)與網(wǎng)絡(luò)構(gòu)成物理連接。如果這項(xiàng)檢測(cè)的結(jié)果為“no”，那么我們需要親自檢查dev1的網(wǎng)絡(luò)連接，并將線纜插實(shí)到位。在確定物理連接沒(méi)有問(wèn)題之后，執(zhí)行下面的步驟。

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

$ sudo ethtool -s eth0 autoneg off duplex full

意思是利用自己的以太網(wǎng)設(shè)備代替eth0。

端口正常嗎？

一旦確認(rèn)了服務(wù)器與網(wǎng)絡(luò)之間物理連接的完好性，接下來(lái)就是判斷主機(jī)上的網(wǎng)絡(luò)端口是否配置正確。在這方面，***的檢查方式就是運(yùn)行ifconfig命令并將端口作為參數(shù)后綴。因此要測(cè)試eth0的設(shè)置，大家應(yīng)該運(yùn)行以下內(nèi)容：

$ 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

在上述輸出結(jié)果中，第二行可能最值得我們關(guān)注，因?yàn)槠鋬?nèi)容是解釋我們的主機(jī)已經(jīng)被配置了一套IP地址（10.1.1.7）與子網(wǎng)掩碼（255.255.255.0）?，F(xiàn)在，大家需要確認(rèn)這樣的設(shè)置結(jié)果是否正確。如果端口未受配置，請(qǐng)嘗試運(yùn)行sudo ifup eth0，然后再次運(yùn)行ifconfig重新檢查端口是否出現(xiàn)。如果設(shè)置錯(cuò)誤或端口未出現(xiàn)，則檢查/etc/network/interfaces路徑（Debian系統(tǒng)）或/etc/-sysconfig/-network_scripts/ifcfg-<interface>路徑（紅帽系統(tǒng)）。在這些文件中，大家可以修正網(wǎng)絡(luò)設(shè)置中存在的所有錯(cuò)誤?，F(xiàn)在如果主機(jī)通過(guò)DHCP獲得自身IP，我們則需要將故障排查轉(zhuǎn)移到DHCP主機(jī)處，找出為什么我們沒(méi)有正確獲得IP租用周期。

問(wèn)題出在本地網(wǎng)絡(luò)中嗎？

排除了端口出現(xiàn)的問(wèn)題之后，接下來(lái)我們就該檢查默認(rèn)網(wǎng)關(guān)是否被設(shè)置及我們能否對(duì)其進(jìn)行訪問(wèn)。route命令將顯示出我們當(dāng)前的路由表，包括默認(rèn)網(wǎng)關(guān)：

$ 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

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

$ sudo service networking restart

而在紅帽系統(tǒng)中我們需要運(yùn)行如下命令進(jìn)行端口重置：

$ sudo service network restart

請(qǐng)大家注意，即使是如此基本的操作命令在不同的系統(tǒng)發(fā)行版中也存在著差異。

一旦確認(rèn)網(wǎng)關(guān)配置完成，我們可以利用ping命令來(lái)確認(rèn)與網(wǎng)關(guān)的通信效果：

$ 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

如大家所見(jiàn)，我們已經(jīng)能夠正確ping通網(wǎng)關(guān)，這至少意味著大家與10.1.1.0網(wǎng)絡(luò)能夠進(jìn)行通信。如果無(wú)法ping通網(wǎng)關(guān)，那么原因可能分以下幾種。首先，這可能表示我們的網(wǎng)關(guān)自動(dòng)阻斷ICMP數(shù)據(jù)包。如果是這樣，請(qǐng)告訴網(wǎng)絡(luò)管理員阻斷ICMP是種討厭的壞習(xí)慣，由此帶來(lái)的安全收益也微乎其微。然后嘗試ping同一子網(wǎng)下的另一臺(tái)Linux主機(jī)。如果ICMP沒(méi)有被阻斷，那么可能是主機(jī)交換機(jī)端口的VLAN設(shè)置有誤，所以我們需要進(jìn)一步檢查接入的交換機(jī)。

DNS能正常工作嗎？

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

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

如上所示，實(shí)例中的DNS服務(wù)器能夠正常工作。web1主機(jī)擴(kuò)展為web1.example.net且被解析為10.1.2.5地址。當(dāng)然，大家別忘了確認(rèn)解析出的IP地址與web1應(yīng)該使用的IP地址相匹配。在本實(shí)例中，因?yàn)镈NS沒(méi)有問(wèn)題，所以我們可以直接跳到下一部分；但有時(shí)候DNS也可能出現(xiàn)問(wèn)題。

沒(méi)有配置過(guò)的名稱服務(wù)器或無(wú)法訪問(wèn)名稱服務(wù)器

如果大家看到如下錯(cuò)誤，這可能意味著要么我們的主機(jī)沒(méi)有配置過(guò)的名稱服務(wù)器，要么這些服務(wù)器無(wú)法進(jìn)行訪問(wèn)：

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

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

search example.net
nameserver 10.1.1.3

如果無(wú)法ping通名稱服務(wù)器，且其IP地址與我們的主機(jī)處于同一子網(wǎng)下（在本實(shí)例中，10.1.1.3代表處于同一子網(wǎng)下），則代表名稱服務(wù)器本身可能已經(jīng)崩潰。如果無(wú)法ping通名稱服務(wù)器且其IP地址與我們的主機(jī)處于不同子網(wǎng)下，則直接跳轉(zhuǎn)至"我能路由至遠(yuǎn)程主機(jī)嗎？"章節(jié)，選擇其中與名稱服務(wù)器IP故障排查相關(guān)的內(nèi)容加以執(zhí)行。如果通過(guò)ping通名稱服務(wù)器但對(duì)方無(wú)響應(yīng)，則跳轉(zhuǎn)至"遠(yuǎn)程端口是否打開(kāi)？”章節(jié)。

缺少搜索路徑或名稱服務(wù)器的問(wèn)題

在運(yùn)行nslookup命令后，我們還可能得到以下錯(cuò)誤信息：

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

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

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

我能路由至遠(yuǎn)程主機(jī)嗎？

在排除了DNS問(wèn)題并看到web1被正確解析為IP 10.1.2.5之后，大家需要測(cè)試自己能否路由至遠(yuǎn)程主機(jī)。假如我們的網(wǎng)絡(luò)啟用了ICMP，那么最快捷的測(cè)試辦法是ping web1。如果該主機(jī)能被ping通，我們就知道數(shù)據(jù)包已經(jīng)被路由至目的地，這樣的話可以直接跳轉(zhuǎn)至"遠(yuǎn)程端口打開(kāi)了嗎？"章節(jié)。如果無(wú)法ping通web1，則嘗試與網(wǎng)絡(luò)中的另一臺(tái)主機(jī)通信看看能否ping通。如果我們無(wú)法在遠(yuǎn)程網(wǎng)絡(luò)中ping通任何主機(jī)，就說(shuō)明數(shù)據(jù)包無(wú)法被正確路由。***的路由問(wèn)題測(cè)試工具這一就是traceroute。一旦與一臺(tái)主機(jī)建立起路由追蹤，它會(huì)測(cè)試我們與主機(jī)之間的每一次數(shù)據(jù)包跳轉(zhuǎn)。舉例來(lái)說(shuō)，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

這里我們會(huì)看到數(shù)據(jù)包從dev1到達(dá)其網(wǎng)關(guān)（10.1.1.1），然后再跳轉(zhuǎn)至web1。這代表著起始位置與目標(biāo)主機(jī)可能都采用10.1.1.1網(wǎng)關(guān)。如果大家的操作環(huán)境中存在更多路由中轉(zhuǎn)點(diǎn)，那么顯示的結(jié)果可能與上述內(nèi)容有所不同。如果無(wú)法ping通web1，那么輸入結(jié)果將如下所示：

$ 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 * * *

一旦我們?cè)谳敵鼋Y(jié)果中看到星號(hào)，就說(shuō)明問(wèn)題出在網(wǎng)關(guān)方面。大家需要從路由器著手，看看為什么它無(wú)法在兩套網(wǎng)絡(luò)之間路由數(shù)據(jù)包。通過(guò)追蹤，大家會(huì)看到如下內(nèi)容：

$ 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

在這種情況下，我們發(fā)現(xiàn)ping操作在網(wǎng)關(guān)環(huán)節(jié)出現(xiàn)了超時(shí)，這說(shuō)明該主機(jī)可能已經(jīng)崩潰或無(wú)法通過(guò)同一子網(wǎng)進(jìn)行訪問(wèn)。有鑒于此，如果大家還沒(méi)有從同一子網(wǎng)下的其它設(shè)備訪問(wèn)過(guò)web1，請(qǐng)嘗試ping及其它測(cè)試。

注意：如果某套煩人的網(wǎng)絡(luò)仍然在阻斷ICMP，不用擔(dān)心，我們?nèi)匀挥修k法進(jìn)行路由排查工作。大家只需要安裝tcptraceroute軟件包(sudo apt-get install tcptraceroute)然后運(yùn)行相同的路由追蹤命令，惟一的區(qū)別是用tcptraceroute來(lái)代替traceroute 。

遠(yuǎn)程端口打開(kāi)了嗎？

現(xiàn)在我們已經(jīng)能夠路由至目標(biāo)設(shè)備，但仍然無(wú)法在端口80上訪問(wèn)web服務(wù)器。接下來(lái)的測(cè)試意在檢查端口是否打開(kāi)。要實(shí)現(xiàn)這一目的，我們可以選擇的方案很多。選擇其一，我們可以嘗試telnet：

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

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

但相對(duì)于telnet，我個(gè)人更偏向使用nmap來(lái)進(jìn)行端口測(cè)試，因?yàn)樗軌驒z測(cè)到防火墻的影響。如果大家還沒(méi)有安裝nmap，可以使用軟件包管理器快速安裝nmap軟件包。要對(duì)web1進(jìn)行測(cè)試，請(qǐng)輸入以下內(nèi)容：

$ 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果然不負(fù)眾望，它一般都能發(fā)現(xiàn)所謂"關(guān)閉的端口"到底是直接處于關(guān)閉狀態(tài)、還是在防火墻后處于關(guān)閉狀態(tài)。通常情況下，nmap會(huì)將真正關(guān)閉的端口報(bào)告為"關(guān)閉"，而將防火墻后的端口報(bào)告為"過(guò)濾"。在我們的測(cè)試中它報(bào)告其狀態(tài)為"過(guò)濾"，意味著期間有防火墻作梗并忽略掉了我們的數(shù)據(jù)包。如此一來(lái)，大家就需要檢查網(wǎng)關(guān)（10.1.1.1）以及web1上的全部防火墻規(guī)則，看看端口80是否處于阻斷狀態(tài)。

在本地測(cè)試遠(yuǎn)程主機(jī)

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

偵聽(tīng)端口測(cè)試

我們?cè)趙eb1上要做的***件事就是測(cè)試端口80是否處于偵聽(tīng)狀態(tài)。大家可以使用netstat -lnp命令來(lái)列出所有打開(kāi)且處于偵聽(tīng)狀態(tài)的端口。我們當(dāng)然可以直接運(yùn)行這條命令并從輸出結(jié)果中篩選出自己想要的結(jié)論，但效率更高的方式則是利用grep指定顯示端口80的偵聽(tīng)狀態(tài)：

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

***列內(nèi)容顯示出端口所使用的傳輸協(xié)議。第二及第三列則顯示接收及發(fā)送隊(duì)列（這里兩者都被設(shè)置為0）?，F(xiàn)在我們要注意的是第四列，因?yàn)樗谐隽酥鳈C(jī)所偵聽(tīng)的本地地址。此處的0.0.0.0：80告訴我們?cè)撝鳈C(jī)正偵聽(tīng)所有端口80流量中與其IP有關(guān)的數(shù)據(jù)。如果Apache只偵聽(tīng)web1的以太網(wǎng)地址，我們將在輸出結(jié)果中看到10.1.2.5：80。

***一列顯示的是哪個(gè)進(jìn)程令端口處于開(kāi)放狀態(tài)。這里我們看到是運(yùn)行中的Apache正在進(jìn)行偵聽(tīng)。如果大家在自己的netstat輸出結(jié)果中沒(méi)有看到這部分內(nèi)容，則需要啟動(dòng)Apache服務(wù)器。

防火墻規(guī)則

如果進(jìn)程正在運(yùn)行且偵聽(tīng)端口80，那就說(shuō)明可能是web1中某種形式的防火墻導(dǎo)致了問(wèn)題的發(fā)生。利用iptables命令列出全部現(xiàn)有防火墻規(guī)則。如果我們的防火墻已被禁用，那么輸出結(jié)果應(yīng)如下所示：

$  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

請(qǐng)注意，默認(rèn)政策被設(shè)置為ACCEPT。盡管規(guī)則本身沒(méi)有問(wèn)題，但防火墻仍然有可能默認(rèn)棄用所有數(shù)據(jù)包。如果屬于這類情況，大家會(huì)看到如下所示的輸出內(nèi)容：

$  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

另一方面，如果某條防火墻規(guī)則阻斷了端口80，那么輸出結(jié)果則應(yīng)如下所示：

$ 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

在后一種情況下，我們顯然需要修改防火墻規(guī)則，以允許服務(wù)器接收來(lái)自端口80的主機(jī)數(shù)據(jù)流量。

網(wǎng)絡(luò)緩慢狀況的故障排查

從某種角度來(lái)說(shuō)，網(wǎng)絡(luò)無(wú)法工作的問(wèn)題更容易解決。當(dāng)一臺(tái)主機(jī)無(wú)法訪問(wèn)，我們可以執(zhí)行前面討論過(guò)的故障排查步驟直到一切恢復(fù)正常。但如果僅僅是網(wǎng)絡(luò)緩慢，追查其根本原因往往變得更為棘手。本章節(jié)將討論一些相關(guān)技巧，幫助大家追蹤導(dǎo)致網(wǎng)絡(luò)速度緩慢的各種原因。

DNS問(wèn)題

雖然DNS在網(wǎng)絡(luò)出現(xiàn)問(wèn)題時(shí)常常蒙冤受責(zé)，但在導(dǎo)致網(wǎng)絡(luò)性能不佳方面，DNS倒真該被優(yōu)先檢查一番。舉例來(lái)說(shuō)，如果我們?yōu)槟硞€(gè)域名配置了兩臺(tái)DNS服務(wù)器，那么在***臺(tái)出現(xiàn)問(wèn)題時(shí)，我們發(fā)出的DNS請(qǐng)求會(huì)等待30秒之后才傳輸至第二臺(tái)DNS服務(wù)器。雖然當(dāng)我們使用像dig或nslookup這樣的工具時(shí)此類情況顯得一目了然，但對(duì)于日常使用來(lái)說(shuō)，DNS故障往往會(huì)以令人意外的方式造成網(wǎng)絡(luò)緩慢；這是因?yàn)橛刑喾?wù)需要借助DNS實(shí)現(xiàn)將主機(jī)名稱解析為IP地址的工作。這些問(wèn)題甚至有可能影響到我們的網(wǎng)絡(luò)故障診斷工具。

Ping、tracerouter、oute、netstat甚至包括iptables在內(nèi)的多款網(wǎng)絡(luò)故障排查工具都會(huì)受到DNS問(wèn)題的牽連而導(dǎo)致速度緩慢。在默認(rèn)情況下，上述所有工具都會(huì)盡可能嘗試將IP地址解析為主機(jī)名稱。一旦DNS服務(wù)器有了毛病，這些命令就會(huì)在查找IP地址的過(guò)程中停滯不前并最終導(dǎo)致執(zhí)行失效。在ping或traceroute方面，問(wèn)題表現(xiàn)為整個(gè)ping應(yīng)答周期耗時(shí)相當(dāng)長(zhǎng)，但最終的請(qǐng)求往返時(shí)間卻比較短。而在netstat與iptables方面，其請(qǐng)求結(jié)果可能會(huì)拖延很久才輸出到屏幕上，這是因?yàn)橄到y(tǒng)一直在等待已經(jīng)超時(shí)的DNS請(qǐng)求。

在前面提到的各種情況中，我們都能很容易地繞過(guò)DNS來(lái)保證故障排查結(jié)果的準(zhǔn)確性。所有列舉的命令都可以通過(guò)添加-n參數(shù)來(lái)禁止其將IP地址解析為主機(jī)名稱。我也是剛剛養(yǎng)成在所有命令后加-n的好習(xí)慣--正如***章提到的那樣--除非我確定自己想解析IP地址。

注意：DNS解析還可能以其它一些意想不到的方式影響我們的web服務(wù)器性能。某些web服務(wù)器會(huì)根據(jù)配置對(duì)訪問(wèn)的***個(gè)IP地址進(jìn)行解析，并將得到的主機(jī)名稱記錄下來(lái)。雖然這會(huì)讓記錄信息更具可讀性，但同時(shí)也會(huì)在出現(xiàn)問(wèn)題時(shí)大大降低web服務(wù)器的速度--例如存在大量訪問(wèn)者時(shí)。這時(shí)web服務(wù)器會(huì)忙著解決這些IP地址的解析工作，而選擇將服務(wù)流量擱置在一邊。

利用traceroute解決網(wǎng)絡(luò)緩慢問(wèn)題

當(dāng)處于不同網(wǎng)絡(luò)中的服務(wù)器與主機(jī)間的連接發(fā)生拖慢狀況時(shí)，我們可能很難追查到真正的罪魁禍?zhǔn)?。尤其是在拖慢以延遲形式（即響應(yīng)所消耗的時(shí)間）出現(xiàn)而不涉及全局帶寬的情況下，真正能力挽狂瀾的就只有traceroute了。正如前文所說(shuō)，tracerout是一種在遠(yuǎn)程網(wǎng)絡(luò)中測(cè)試客戶機(jī)與服務(wù)器間全局連接的有效方式，但它同時(shí)也能有效診斷出導(dǎo)致網(wǎng)絡(luò)緩慢的潛在根源。由于traceroute會(huì)輸出當(dāng)前與目標(biāo)設(shè)備之間每次數(shù)據(jù)轉(zhuǎn)發(fā)所消耗的時(shí)間，因此我們可以利用它追蹤由地域相距過(guò)大或網(wǎng)關(guān)問(wèn)題所引發(fā)的過(guò)載及網(wǎng)絡(luò)緩慢原因。舉例來(lái)說(shuō)，我們利用traceroute檢查美國(guó)與中國(guó)兩邊的雅虎服務(wù)器，輸出結(jié)果如下所示：

$ 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
...

既然不了解有關(guān)網(wǎng)絡(luò)的更多細(xì)節(jié)信息，我們也能夠單純通過(guò)往返時(shí)間把握數(shù)據(jù)包的動(dòng)向。從第九次跳轉(zhuǎn)開(kāi)始，IP地址變成了219.158.30.177，這意味著數(shù)據(jù)包已經(jīng)離開(kāi)美國(guó)抵達(dá)中國(guó)，而跳轉(zhuǎn)的往返時(shí)間也從3毫秒提高到275毫秒。

利用iftop找出是誰(shuí)占用了帶寬

有時(shí)候我們的網(wǎng)絡(luò)緩慢并不是由遠(yuǎn)程服務(wù)器或路由器所引起，而只是因?yàn)橄到y(tǒng)中的某些進(jìn)程占用了太多可用帶寬。雖然從直觀角度我們很難確定哪些進(jìn)程正在使用帶寬，但也有一些工具能幫大家把這些搗蛋的家伙揪出來(lái)。

top就是這樣一款出色的故障排查工具，它的出現(xiàn)還帶來(lái)一系列思路相似的衍生品，例如iotop--能夠確定到底是哪些進(jìn)程占用了大部分磁盤(pán)I/O性能。最終名為iftop的工具橫空出世，能夠在網(wǎng)絡(luò)連接領(lǐng)域提供同等功能。與top不同，iftop不會(huì)親自關(guān)注進(jìn)程情況，而是列出用戶服務(wù)器與遠(yuǎn)程IP之間占用帶寬最多的連接對(duì)象。舉例來(lái)說(shuō)，我們可以在iftop中快速查看備份服務(wù)器IP地址在輸出結(jié)果中的位置來(lái)判斷備份工作有沒(méi)有大量占用網(wǎng)絡(luò)帶寬。

iftop輸出圖示

紅帽與Debian的各個(gè)發(fā)行版都能使用iftop這一名稱的軟件包，但在紅帽發(fā)行版方面大家可能需要從第三方資源庫(kù)才能獲取。一旦安裝過(guò)程完成，我們?cè)诿钚兄羞\(yùn)行iftop命令即可啟用（需要root權(quán)限）。和top命令一樣，我們可以點(diǎn)Q鍵退出。

在iftop界面屏幕的最上方是顯示全局流量的信息欄。信息欄之下則是另外兩列信息，一列為源IP、另一列為目標(biāo)IP，二者之間以箭頭填充幫助我們了解帶寬被用于從自己的主機(jī)向外發(fā)送數(shù)據(jù)還是從遠(yuǎn)程主機(jī)端接收數(shù)據(jù)。再往下則是另外三個(gè)欄位，表示兩臺(tái)主機(jī)之間在2秒、10秒及40秒中的數(shù)據(jù)傳輸速率。與平均負(fù)載相似，大家可以看到目前帶寬使用是否達(dá)到峰值，或者在過(guò)去的哪個(gè)時(shí)段達(dá)到過(guò)峰值。在屏幕的最下方，我們會(huì)找到傳輸數(shù)據(jù)（簡(jiǎn)稱TX）與接收數(shù)據(jù)（簡(jiǎn)稱RX）的總體統(tǒng)計(jì)結(jié)果。與top差不多，iftop的界面也會(huì)定期更新。

在不添加額外參數(shù)的情況下，iftop命令通常能夠滿足我們故障排查的全部需求；但有的時(shí)候，我們可能也希望利用一些選項(xiàng)實(shí)現(xiàn)特殊功能。iftop命令在默認(rèn)情況下會(huì)顯示查找到的***個(gè)端口的統(tǒng)計(jì)信息，但在某些服務(wù)器中大家可能會(huì)使用多個(gè)端口，所以如果我們希望讓iftop打理第二個(gè)以太網(wǎng)端口（即實(shí)例中的eth2），那么請(qǐng)輸入iftop -i eth2。

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

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

與大多數(shù)Linux命令相似，iftop也擁有多種高級(jí)選項(xiàng)。我們?cè)谖恼轮刑岬降倪@些已經(jīng)足以涵蓋大多數(shù)故障排查需求，但為了滿足大家進(jìn)一步了解iftop功能的愿望，我教各位一個(gè)小技巧：只要輸入man iftop，就可以閱讀包含在軟件包當(dāng)中的使用手冊(cè)、獲得更多與之相關(guān)的知識(shí)。

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