前几天，刚和群友讨论过这个问题，他是snmp交换机的时候，图时断时续的。

我这里也出现这样的案例，不过是监控tomcat的时候，jstat占用cpu 90多，

引起正常的监控项目断图。

其实，它让我们wait for 15 seconds，那么意思不断叠加15s后，是不是5分钟后不能出图，

还是负载高不能出图？

案例

zabbix_server.log

12961:20170512:113910.624 Zabbix agent item "java.discovery_status[service_tomcat,all]" on host "172.x.x.x" failed: first network error, wait for 15 seconds

排查

top

top - 14:34:25 up 344 days, 21:11,  1 user,  load average: 1.23, 1.09, 1.10

Tasks: 176 total,   1 running, 174 sleeping,   1 stopped,   0 zombie

Cpu(s): 25.0%us,  5.0%sy,  0.0%ni, 69.7%id,  0.1%wa,  0.0%hi,  0.2%si,  0.0%st

Mem:   3925304k total,  3672532k used,   252772k free,   174944k buffers

Swap:  4128764k total,    79512k used,  4049252k free,  2122448k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                    

2484 tomcat    20   0 3333m  30m  12m S 99.8  0.8   9065:51 jstat

说明jstat异常，这个jstat是zabbix脚本用来获取tomcat数据的。

[root@xx local]# ps -ef|grep jstat
root      2483     1  0 May06 ?        00:00:00 sudo -u tomcat /usr/java/jdk/bin/jstat -gcutil 12470
tomcat    2484  2483 99 May06 ?        6-07:03:49 /usr/java/jdk/bin/jstat -gcutil 12470
root     17095 32501  0 14:32 pts/0    00:00:00 grep jstat
[root@xx local]# ps -ef|grep jstat
root      2483     1  0 May06 ?        00:00:00 sudo -u tomcat /usr/java/jdk/bin/jstat -gcutil 12470
tomcat    2484  2483 99 May06 ?        6-07:04:20 /usr/java/jdk/bin/jstat -gcutil 12470
root     17097 32501  0 14:32 pts/0    00:00:00 grep jstat
解决
kill -9 2484就正常了，重启zabbix_agentd,观察负载为0.5左右。

刚开始怀疑是触发器的问题，还把触发器给禁用了。

至于这个问题的产生原因，有可能有几点
强制杀死tomcat进程引起的
python脚本jstat_status.py调用jstat后，是不是成僵死进程了？
还是这个程序死锁的原因？难道python有什么特别注意的地方?

还需要做的
1.需要用python或者elk分析zabbix server端日志
发现好多not suitable for value type [Numeric (unsigned)] and data type [Decimal]
2.某个进程占用cpu 80以上就是有问题，这个也需要添加监控中

其他断图原因有以下:

1.数据库优化
比如Threads_created   | 4925853
2.zabbix server优化

3.参考菜光光的博客，从sql方面排查
http://caiguangguang.blog.51cto.com/1652935/1377089/
4.网卡问题
http://www.fyluo.com/?post=164
5.ZABBIX AGENT执行KEY,获取数据时间超过30s
参考http://blog.chinaunix.net/uid-8108137-id-4591738.html
解决方案二
修改AGENT执行key的最大时间，源码当中限制了最大时间30S。得修改源码。
并且经过测试只修改AGETN的最大执行时间还不可以，SERVER或PROXY端的最大执行时间也是30S.
只修改AGENT端30S，ITEM可以采集ACTIVE的方式就可以了。

系统的稳定性，才是服务器稳定的前提。

本文出自 “python 运维” 博客，谢绝转载！

断图 first network error, wait for 15 seconds