故障現象：
2014年6月4日 收到客戶郵件說：bjd nagios 的Last Check更新時間與當前時間差距很大
具體處理過程如下：
盲目處理階段：
想將問題儘快處理掉，所以有點只看問題表象忽略了重點，唉，說多了都是淚。
查詢該機器各種log 發現除了一些常規報錯信息，沒有重要發現。
檢查機器磁盤空間，內存，IO，CPU正常。
此問題首次出現，之前未有遇到。通過查詢資料得知是由於此文件權限發生變化導致。但是任我怎麼修改文件的權限和所屬組都不能解決問題。並參考了http://myhat.blog.51cto.com/391263/692879，恕不知此問題不是解決本次問題的關鍵，結果造成誤導。
[root@nagios01 ~]#cd/usr/local/nagios/var/rw/
[root@nagios01 rw]#ll
total 0
prwxrwxrwx 1 nagios nagios 0Jun 7 02:11 nagiosNaNd
5. 繼續爲繞此問題進行分析和嘗試，並進行多次重啓服務操作均未解決，但在重啓服務時發現，服務啓過程中有報錯:/etc/init.d/nagios: line 67: kill: (1777) - No such process 在之前重啓服務中均未出現此問題，覺得應該不正常，於是查之，陷於分析過程，參考網絡文章無數未找到解決方法，先忽略之。此時主服務一直未啓動具然不知道，並且沒有引起足夠的重視。
6. 比對運行正常的機器，各種比對，配置文件均一致，無解。
7. 沒有找到合理的解決方法，重啓機器，重啓完成後未解決，心灰意冷了。
8. 由於時間差距大，與用戶商議先決定開啓備機上的報警功能，。
9. 備機啓動時也是多災多難，不過最終切至備機上開始運行。
10. 關閉當前機器報警功能，讓同事將此機器生成快照，爲了日後找到問題時回退。
11. 把之間忽略的信息重新分析並解決，但問題已然存在。
n 發現轉折點階段：
1. 備機開啓，沒有什麼提心了，繼續排查。
2. 此時發現nagios主服務未啓動，但是web訪問的頁面也能打開，各種數據都有，詫異各種詫異，之前的處理都是被誤導到天國去了。
3. 隨即開啓nagios主程序，發現啓動1-3分鐘後就自動停止。於是先打開日誌文件保持更新狀態，一邊開啓nagios主程序，觀察啓動過程。這次在日誌中有重大發現：
啓動nagios時在系統日誌中出現如下報錯信息：
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!
4. 當nagios自動停止後，此日誌不在出現，根據經驗判斷有重大嫌疑，於時查之。隨着深入查閱資料更能加深這一判斷：
此問題爲inodes(索引節點)已滿,引用"inode譯成中文就是索引節點，每個存儲設備（例如硬盤）或存儲設備的分區被格式化爲文件系統後，應該有兩部份，一部份是inode，另一部份是Block，Block是用來存儲數據用的。而inode呢，就是用來存儲這些數據的信息，這些信息包括文件大小、屬主、歸屬的用戶組、讀寫權限等。inode爲每個文件進行信息索引，所以就有了inode的數值。操作系統根據指令，能通過inode值最快的 找到相對應的文件。"通過幾臺的情分析判斷,每一G的空間,有120000左右的inodes可以在格式化分區時指定inodes的大小,加個 -N參數,如
mkfs.ext3 -N 2500000/dev/sda6 #2500000 爲inodes的大小
實際應用需要要根據分區的大小來定，造成此問題通常是產生了大量的小文件（附合nagios的特點）
5. 再進一步落實
檢查磁盤空是未滿，但是檢查Inodes時發現 /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]#
6. 繼續確認：
在/data/pnp4/pnp4nagios/var/spool這個目錄下有18G的文件，都是小文件有46萬多個
[root@nagios02 spool]#find .-type f |wc -l
468954
定位問題階段：
是存放pnp4nagios的數據文件，Pnp4nagios使用的是RRDtool工具來實現畫圖的，用rrdtool是將nagios採集的數據繪製圖表的工具。簡單來說就是對於服務和主機，添加“小太陽”監控圖標來使的，是歷史數據。
經過以上的落實確認基本上可以判定，由於inodes(索引節點)已滿，造成的nagios程序啓動後自動停止。
解決問題：
刪除小文件/data/pnp4/pnp4nagios/var/spool
重啓nagios 主服務一切正常，問題解決。
經刪除這些文件後，驗證了小太陽中的歷史數據圖表還有數據，證明可以刪除，沒有影響。
個人總結：
遇到問題不要慌，亂了陣腳，不可取。
判斷問題要用排除法，不能頭腦發熱和想當然，否則會給後續判斷帶來重大的方向性錯誤。
實在沒法的時候就要把所有懷疑的關鍵點逐個進行落實和分析，得出一條關鍵路徑，最後得出正確的方向。
請教人不如自己查，在關鍵問題上還是要靠本人。雖然對方是高手，但是通過電話或郵件根本不可能描述你所面臨的問題，因爲你還有沒定位問題的所在，多少次的經驗驗證了這一條。但不是說不讓問，度希望自己揣摩和掌握。
強烈推薦googlebaidu ,沒有強大的搜索功能，也不會締造我們這些IT民工的成長，謝謝你們。
吐槽國內的某些組織，google，google，google，上不去啊。
有些手冊還需完善和建立。
以上代表個人關點，如有不同意見線下來討論。
後續工作：
目前還建議切換回10.219.240.12，因爲在處理過程中修改了很多配置文件參數。
運行一段時間看看效果，觀察觀察。
觀察後沒問題，需要將做的快照恢復到之前。並從10.219.240.35上將監控狀態信息同步到10.219.240.12上。
還有一些技術問題需要討論。
附贈送一點Linux 小知識共勉：
在Linux 下刪除大文件時有時會用到這個命令：
測試時在目錄下創建了20w個左右的空文件，想刪除這些文件，進入目錄，輸入命令：
rm -rf *
屏幕顯示：
-bash: /bin/rm: Argument list too long
通過google後，找到解決方法，輸入下面的命令，刪除成功：
ls | xargs -n 10 rm -fr ls
命令解釋爲：輸出所有的文件名(用空格分割) xargs就是將ls的輸出，每10個爲一組(以空格爲分隔符)，作爲rm -rf的參數也就是說將所有文件名10個爲一組，由rm -rf刪除
Linux下面查看目錄大小以及文件數量命令
查看目錄的大小:
[root@vps 1010 shellimage]#du -sh
上面這個是查看當前目錄的大小，如果是要查看指定目錄的大小則：
[root@vps 1010 shellimage]#du -sh/uploadimages
這裏是查看根目錄下的uploadimages目錄的大小.
2.查看當前目錄文件總數:
[root@vps 1010 shellimage]#find .-type f |wc -l
上面這個是查看當前目錄文件總數,如果是要查看指定目錄的總數則：
[root@vps 1010shellimage]#find /uploadimages -type f |wc -l
這裏的f是表示文件,改成d則表示目錄.