Centos-Nagios的LastCheck更新时间与当前时间差距分析问题及处理方法总结

故障现象：

创新互联业务包括：成品网站、企业产品展示型网站建设、品牌网站建设、电子商务型网站建设、成都外贸网站建设公司(多语言)、商城网站建设、按需定制开发、全网整合营销推广等。效率优先，品质保证，用心服务是我们的核心价值观，我们将继续以良好的信誉为基础，秉承稳固与发展、求实与创新的精神，为客户提供更全面、更优质的互联网服务！

• 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

1. 5.    继续为绕此问题进行分析和尝试，并进行多次重启服务操作均未解决，但在重启服务时发现，服务启过程中有报错:/etc/init.d/nagios: line 67: kill: (1777) - No such process 在之前重启服务中均未出现此问题，觉得应该不正常，于是查之，陷于分析过程，参考网络文章无数未找到解决方法，先忽略之。此时主服务一直未启动具然不知道，并且没有引起足够的重视。

2. 6.    比对运行正常的机器，各种比对，配置文件均一致，无解。

3. 7.    没有找到合理的解决方法，重启机器，重启完成后未解决，心灰意冷了。

4. 8.    由于时间差距大，与用户商议先决定开启备机上的报警功能，。

5. 9.    备机启动时也是多灾多难，不过最终切至备机上开始运行。

6. 10. 关闭当前机器报警功能，让同事将此机器生成快照，为了日后找到问题时回退。

7. 11. 把之间忽略的信息重新分析并解决，但问题已然存在。

8. n 发现转折点阶段：

9. 1.    备机开启，没有什么提心了，继续排查。

10. 2.    此时发现nagios主服务未启动，但是web访问的页面也能打开，各种数据都有，诧异各种诧异，之前的处理都是被误导到天国去了。

11. 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!

1. 4.    当nagios自动停止后，此日志不在出现，根据经验判断有重大嫌疑，于时查之。随着深入查阅资料更能加深这一判断：

找到相关资料http://www.linuxquestions.org/questions/linux-server-73/ext3-fs-warning-device-dm-0-ext3dxaddentry-directory-index-full-631376/

此问题为inodes(索引节点)已满,引用"inode译成中文就是索引节点，每个存储设备（例如硬盘）或存储设备的分区被格式化为文件系统后，应该有两部份，一部份是inode，另一部份是Block，Block是用来存储数据用的。而inode呢，就是用来存储这些数据的信息，这些信息包括文件大小、属主、归属的用户组、读写权限等。inode为每个文件进行信息索引，所以就有了inode的数值。操作系统根据指令，能通过inode值最快的 找到相对应的文件。"通过几台的情分析判断,每一G的空间,有120000左右的inodes可以在格式化分区时指定inodes的大小,加个 -N参数,如

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

实际应用需要要根据分区的大小来定，造成此问题通常是产生了大量的小文件（附合nagios的特点）

1. 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]#

1. 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 主服务一切正常，问题解决。

经删除这些文件后，验证了小太阳中的历史数据图表还有数据，证明可以删除，没有影响。

个人总结：

1. 遇到问题不要慌，乱了阵脚，不可取。

2. 判断问题要用排除法，不能头脑发热和想当然，否则会给后续判断带来重大的方向性错误。

3. 实在没法的时候就要把所有怀疑的关键点逐个进行落实和分析，得出一条关键路径，最后得出正确的方向。

4. 请教人不如自己查，在关键问题上还是要靠本人。虽然对方是高手，但是通过电话或邮件根本不可能描述你所面临的问题，因为你还有没定位问题的所在，多少次的经验验证了这一条。但不是说不让问，度希望自己揣摩和掌握。

5. 强烈推荐googlebaidu ,没有强大的搜索功能，也不会缔造我们这些IT民工的成长，谢谢你们。

6. 吐槽国内的某些组织，google，google，google，上不去啊。

7. 有些手册还需完善和建立。

以上代表个人关点，如有不同意见线下来讨论。

后续工作：

1. 目前还建议切换回10.219.240.12，因为在处理过程中修改了很多配置文件参数。

2. 运行一段时间看看效果，观察观察。

3. 观察后没问题，需要将做的快照恢复到之前。并从10.219.240.35上将监控状态信息同步到10.219.240.12上。

4. 还有一些技术问题需要讨论。

附赠送一点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 shellp_w_picpath]#du -sh

上面这个是查看当前目录的大小，如果是要查看指定目录的大小则：

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

这里是查看根目录下的uploadp_w_picpaths目录的大小.

2.查看当前目录文件总数:

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

上面这个是查看当前目录文件总数,如果是要查看指定目录的总数则：

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

这里的f是表示文件,改成d则表示目录.