线上使用zabbix的host update来监测监控值是否完整（关于host update的实现请参考：
）
一直发现有机器过一段时间update值就会莫名其妙变低，之前一直没有找到rc，只是简单通过重启agent来进行修复，最近同事细心地发现可能是和sudo的bug有关系。
回过头再来验证下整个的排查过程。
1.通过zabbix 数据库获取丢失数据的item，拿出缺失的(20分钟没有更新的)值的item列表
selectb.key_,b.lastvalue,from_unixtime(b.lastclock)fromhostsa,itemsbwherea.hostid=b.hostidanda.host=’xxxxxx’andb.lastclock<(unix_timestamp()-1200)limit10;
比如这里看agent.ping:
观察监控图，发现在18点20分之后数据丢失：
2.分析zabbix agent端的日志
发现在18点24粉左右出现下面的日志，没有看到正常的获取值和发送值的情况，只有大量的update_cpustats状态，同时发现有一行kill command 失败的日志:
27589:20141021:182442.143Inzbx_popen()command:’sudohadoop_stats.shnodemanagerStopContainerAvgTime’27589:20141021:182442.143Endofzbx_popen():548430:20141021:182442.143zbx_popen():executingscript27585:20141021:182442.284Inupdate_cpustats()27585:20141021:182442.285Endofupdate_cpustats()27585:20141021:182443.285Inupdate_cpustats()27585:20141021:182443.286Endofupdate_cpustats()27585:20141021:182444.286Inupdate_cpustats()27585:20141021:182444.287Endofupdate_cpustats()27585:20141021:182445.287Inupdate_cpustats()27585:20141021:182445.287Endofupdate_cpustats()27585:20141021:182446.288Inupdate_cpustats()27585:20141021:182446.288Endofupdate_cpustats()……….27585:20141021:182508.305Inupdate_cpustats()27585:20141021:182508.305Endofupdate_cpustats()27585:20141021:182509.306Inupdate_cpustats()27585:20141021:182509.306Endofupdate_cpustats()27585:20141021:182510.306Inupdate_cpustats()27585:20141021:182510.307Endofupdate_cpustats()27585:20141021:182511.307Inupdate_cpustats()27585:20141021:182511.308Endofupdate_cpustats()27589:20141021:182512.154failedtokill[sudohadoop_stats.shnodemanagerStopContainerAvgTime]:[1]Operationnotpermitted27589:20141021:182512.155Inzbx_waitpid()27585:20141021:182512.308Inupdate_cpustats()27585:20141021:182512.309Endofupdate_cpustats()27585:20141021:182513.309Inupdate_cpustats()27585:20141021:182513.309Endofupdate_cpustats()
对比正常的日志：
27589:20141021:180054.376Inzbx_popen()command:’sudohadoop_stats.shnodemanagerStopContainerAvgTime’27589:20141021:180054.377Endofzbx_popen():518798:20141021:180054.377zbx_popen():executingscript27589:20141021:180054.384Inzbx_waitpid()27589:20141021:180054.384zbx_waitpid()exited,status:127589:20141021:180054.384Endofzbx_waitpid():1879827589:20141021:180054.384Runremotecommand[sudohadoop_stats.shnodemanagerStopContainerAvgTime]Result[2][-1]…27589:20141021:180054.384Forkey[hadoop_stats[nodemanager,StopContainerAvgTime]]receivedvalue[-1]27589:20141021:180054.384Inprocess_value()key:’gd6g203s80-hadoop-datanode.idc.vipshop.com:hadoop_stats[nodemanager,StopContainerAvgTime]’value:’-1’27589:20141021:180054.384Insend_buffer()host:’10.200.100.28’port:10051values:37/5027589:20141021:180054.384Willnotsendnow.Now1413885654lastsent1413885654<127589:20141021:180054.385Endofsend_buffer():SUCCEED27589:20141021:180054.385buffer:newelement3727589:20141021:180054.385Endofprocess_value():SUCCEED
可以看到正常情况下脚本会有返回值，，而出问题的时候，脚本是没有返回值的，并且由于是使用sudo 运行脚本，导致以普通用户启动的zabbix在超时时没有办法杀掉这个command(Operation not permitted错误)
3.假设这里启动zabbix agent的普通用户为apps用户，我们看下这个脚本目前的状态
ps-ef|grephadoop_stats.shroot3449431429012:54pts/000:00:00grep48430root48430275890Oct21?00:00:00sudohadoop_stats.shnodemanagerStopContainerAvgTimeroot48431484300Oct21?00:00:00[hadoop_stats.sh]<defunct>
可以看到，这里产生了一个僵尸进程（关于僵尸进程可以参考：）
真凉爽啊！青山绿水映入我的眼中，景色怡人啊！
