Centos-Nagios的LastCheck更新时间与当前时间差距分析问题及处理方法总结-成都创新互联网站建设

关于创新互联

多方位宣传企业产品与服务 突出企业形象

公司简介 公司的服务 荣誉资质 新闻动态 联系我们

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. 发现转折点阶段:

  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则表示目录.


分享标题:Centos-Nagios的LastCheck更新时间与当前时间差距分析问题及处理方法总结
网站URL:http://kswsj.cn/article/ppdsdj.html

其他资讯