故障現(xiàn)象：

創(chuàng)新互聯(lián)業(yè)務(wù)包括：成品網(wǎng)站、企業(yè)產(chǎn)品展示型網(wǎng)站建設(shè)、品牌網(wǎng)站建設(shè)、電子商務(wù)型網(wǎng)站建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)公司(多語言)、商城網(wǎng)站建設(shè)、按需定制開發(fā)、全網(wǎng)整合營銷推廣等。效率優(yōu)先，品質(zhì)保證，用心服務(wù)是我們的核心價值觀，我們將繼續(xù)以良好的信譽為基礎(chǔ)，秉承穩(wěn)固與發(fā)展、求實與創(chuàng)新的精神，為客戶提供更全面、更優(yōu)質(zhì)的互聯(lián)網(wǎng)服務(wù)！

• 2014年6月4日 收到客戶郵件說：bjd nagios 的Last Check更新時間與當(dāng)前時間差距很大

具體處理過程如下：

• 盲目處理階段：

• 想將問題盡快處理掉，所以有點只看問題表象忽略了重點，唉，說多了都是淚。

• 查詢該機器各種log 發(fā)現(xiàn)除了一些常規(guī)報錯信息，沒有重要發(fā)現(xiàn)。

• 檢查機器磁盤空間，內(nèi)存，IO，CPU正常。

• 此問題首次出現(xiàn)，之前未有遇到。通過查詢資料得知是由于此文件權(quán)限發(fā)生變化導(dǎo)致。但是任我怎么修改文件的權(quán)限和所屬組都不能解決問題。并參考了http://myhat.blog.51cto.com/391263/692879，恕不知此問題不是解決本次問題的關(guān)鍵，結(jié)果造成誤導(dǎo)。

[root@nagios01 ~]#cd/usr/local/nagios/var/rw/

[root@nagios01 rw]#ll

total 0

prwxrwxrwx 1 nagios nagios 0Jun  7 02:11 nagiosNaNd

1. 5.    繼續(xù)為繞此問題進行分析和嘗試，并進行多次重啟服務(wù)操作均未解決，但在重啟服務(wù)時發(fā)現(xiàn)，服務(wù)啟過程中有報錯:/etc/init.d/nagios: line 67: kill: (1777) - No such process 在之前重啟服務(wù)中均未出現(xiàn)此問題，覺得應(yīng)該不正常，于是查之，陷于分析過程，參考網(wǎng)絡(luò)文章無數(shù)未找到解決方法，先忽略之。此時主服務(wù)一直未啟動具然不知道，并且沒有引起足夠的重視。

2. 6.    比對運行正常的機器，各種比對，配置文件均一致，無解。

3. 7.    沒有找到合理的解決方法，重啟機器，重啟完成后未解決，心灰意冷了。

4. 8.    由于時間差距大，與用戶商議先決定開啟備機上的報警功能，。

5. 9.    備機啟動時也是多災(zāi)多難，不過最終切至備機上開始運行。

6. 10. 關(guān)閉當(dāng)前機器報警功能，讓同事將此機器生成快照，為了日后找到問題時回退。

7. 11. 把之間忽略的信息重新分析并解決，但問題已然存在。

8. n 發(fā)現(xiàn)轉(zhuǎn)折點階段：

9. 1.    備機開啟，沒有什么提心了，繼續(xù)排查。

10. 2.    此時發(fā)現(xiàn)nagios主服務(wù)未啟動，但是web訪問的頁面也能打開，各種數(shù)據(jù)都有，詫異各種詫異，之前的處理都是被誤導(dǎo)到天國去了。

11. 3.    隨即開啟nagios主程序，發(fā)現(xiàn)啟動1-3分鐘后就自動停止。于是先打開日志文件保持更新狀態(tài)，一邊開啟nagios主程序，觀察啟動過程。這次在日志中有重大發(fā)現(xiàn)：

啟動nagios時在系統(tǒng)日志中出現(xiàn)如下報錯信息：

Jun  7 00:41:41nagios01 kernel: EXT3-fs warning (device dm-0): ext3_dx_add_entry: Directoryindex full!

Jun  7 00:41:41nagios01 kernel: EXT3-fs warning (device dm-0): ext3_dx_add_entry: Directoryindex full!

Jun  7 00:41:50nagios01 /usr/sbin/gmetad[2964]: data_thread() got no answer from any [MonitorHost] datasource

Jun  7 00:41:56nagios01 kernel: EXT3-fs warning (device dm-0): ext3_dx_add_entry: Directoryindex full!

Jun  7 00:41:56nagios01 kernel: EXT3-fs warning (device dm-0): ext3_dx_add_entry: Directoryindex full!

1. 4.    當(dāng)nagios自動停止后，此日志不在出現(xiàn)，根據(jù)經(jīng)驗判斷有重大嫌疑，于時查之。隨著深入查閱資料更能加深這一判斷：

找到相關(guān)資料http://www.linuxquestions.org/questions/linux-server-73/ext3-fs-warning-device-dm-0-ext3dxaddentry-directory-index-full-631376/

此問題為inodes(索引節(jié)點)已滿,引用"inode譯成中文就是索引節(jié)點，每個存儲設(shè)備（例如硬盤）或存儲設(shè)備的分區(qū)被格式化為文件系統(tǒng)后，應(yīng)該有兩部份，一部份是inode，另一部份是Block，Block是用來存儲數(shù)據(jù)用的。而inode呢，就是用來存儲這些數(shù)據(jù)的信息，這些信息包括文件大小、屬主、歸屬的用戶組、讀寫權(quán)限等。inode為每個文件進行信息索引，所以就有了inode的數(shù)值。操作系統(tǒng)根據(jù)指令，能通過inode值最快的 找到相對應(yīng)的文件。"通過幾臺的情分析判斷,每一G的空間,有120000左右的inodes可以在格式化分區(qū)時指定inodes的大小,加個 -N參數(shù),如

mkfs.ext3 -N 2500000/dev/sda6 #2500000 為inodes的大小

實際應(yīng)用需要要根據(jù)分區(qū)的大小來定，造成此問題通常是產(chǎn)生了大量的小文件（附合nagios的特點）

1. 5.    再進一步落實

檢查磁盤空是未滿，但是檢查Inodes時發(fā)現(xiàn) /data目錄還有1%

[root@nagios01 etc]#df -i

Filesystem           Inodes   IUsed   IFree IUse% Mounted on

/dev/sda3             65952   10062   55890   16% /

/dev/mapper/lv01-vm01

                   12816384   66867 12749517    1% /data

/dev/sda8             65952      90   65862    1%/tmp

/dev/sda7            328000   23317  304683    8% /home

/dev/sda6            655360   10724  644636    2% /var

/dev/sda5            655360  100483  554877   16% /usr

/dev/sda1             26104      44   26060    1%/boot

tmpfs               1021913       1 1021912    1%/dev/shm

[root@nagios01 etc]#df -h

Filesystem           Size  Used Avail Use% Mounted on

/dev/sda3           1020M  477M  492M  50% /

/dev/mapper/lv01-vm01

                      48G   35G   11G  77% /data

/dev/sda8           1020M   35M  934M   4% /tmp

/dev/sda7            5.0G  2.4G  2.4G  50% /home

/dev/sda6             10G  2.7G  6.8G  29% /var

/dev/sda5             10G  2.2G  7.3G  24% /usr

/dev/sda1             99M   23M   71M  25% /boot

tmpfs                3.9G     0  3.9G   0% /dev/shm

[root@nagios01 etc]#

1. 6.    繼續(xù)確認(rèn)：

在/data/pnp4/pnp4nagios/var/spool這個目錄下有18G的文件，都是小文件有46萬多個

[root@nagios02 spool]#find .-type f |wc -l

468954

• 定位問題階段：

• 是存放pnp4nagios的數(shù)據(jù)文件，Pnp4nagios使用的是RRDtool工具來實現(xiàn)畫圖的，用rrdtool是將nagios采集的數(shù)據(jù)繪制圖表的工具。簡單來說就是對于服務(wù)和主機，添加“小太陽”監(jiān)控圖標(biāo)來使的，是歷史數(shù)據(jù)。

• 經(jīng)過以上的落實確認(rèn)基本上可以判定，由于inodes(索引節(jié)點)已滿，造成的nagios程序啟動后自動停止。

• 解決問題：

刪除小文件/data/pnp4/pnp4nagios/var/spool

重啟nagios 主服務(wù)一切正常，問題解決。

經(jīng)刪除這些文件后，驗證了小太陽中的歷史數(shù)據(jù)圖表還有數(shù)據(jù)，證明可以刪除，沒有影響。

個人總結(jié)：

1. 遇到問題不要慌，亂了陣腳，不可取。

2. 判斷問題要用排除法，不能頭腦發(fā)熱和想當(dāng)然，否則會給后續(xù)判斷帶來重大的方向性錯誤。

3. 實在沒法的時候就要把所有懷疑的關(guān)鍵點逐個進行落實和分析，得出一條關(guān)鍵路徑，最后得出正確的方向。

4. 請教人不如自己查，在關(guān)鍵問題上還是要靠本人。雖然對方是高手，但是通過電話或郵件根本不可能描述你所面臨的問題，因為你還有沒定位問題的所在，多少次的經(jīng)驗驗證了這一條。但不是說不讓問，度希望自己揣摩和掌握。

5. 強烈推薦googlebaidu ,沒有強大的搜索功能，也不會締造我們這些IT民工的成長，謝謝你們。

6. 吐槽國內(nèi)的某些組織，google，google，google，上不去啊。

7. 有些手冊還需完善和建立。

以上代表個人關(guān)點，如有不同意見線下來討論。

后續(xù)工作：

1. 目前還建議切換回10.219.240.12，因為在處理過程中修改了很多配置文件參數(shù)。

2. 運行一段時間看看效果，觀察觀察。

3. 觀察后沒問題，需要將做的快照恢復(fù)到之前。并從10.219.240.35上將監(jiān)控狀態(tài)信息同步到10.219.240.12上。

4. 還有一些技術(shù)問題需要討論。

附贈送一點Linux小知識共勉：

• 在Linux 下刪除大文件時有時會用到這個命令：

測試時在目錄下創(chuàng)建了20w個左右的空文件，想刪除這些文件，進入目錄，輸入命令：
rm -rf *
屏幕顯示：
-bash: /bin/rm: Argument list too long
通過google后，找到解決方法，輸入下面的命令，刪除成功：
ls | xargs -n 10 rm -fr ls
命令解釋為：輸出所有的文件名(用空格分割) xargs就是將ls的輸出，每10個為一組(以空格為分隔符)，作為rm -rf的參數(shù)也就是說將所有文件名10個為一組，由rm -rf刪除

• Linux下面查看目錄大小以及文件數(shù)量命令

• 查看目錄的大小:
  [root@vps 1010 shellp_w_picpath]#du -sh

上面這個是查看當(dāng)前目錄的大小，如果是要查看指定目錄的大小則：

[root@vps 1010 shellp_w_picpath]#du -sh/uploadp_w_picpaths

這里是查看根目錄下的uploadp_w_picpaths目錄的大小.

2.查看當(dāng)前目錄文件總數(shù):

[root@vps 1010 shellp_w_picpath]#find .-type f |wc -l

上面這個是查看當(dāng)前目錄文件總數(shù),如果是要查看指定目錄的總數(shù)則：

[root@vps 1010shellp_w_picpath]#find /uploadp_w_picpaths -type f |wc -l

這里的f是表示文件,改成d則表示目錄.