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
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自动停止后,此日志不在出现,根据经验判断有重大嫌疑,于时查之。随着深入查阅资料更能加深这一判断:
找到相关资料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的特点)
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 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://pwwzsj.com/article/ppdsdj.html