故障现象：
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则表示目录.
本文出自 “实用笔记” 博客，请务必保留此出处http://qiuyt.blog.51cto.com/1229789/1424356
Centos- Nagios 的Last Check更新时间与当前时间差距分析问题及处理方法总结,布布扣,bubuko.com