一次大批量java应用程序存活zabbix告警

晚上突然收到zabbix告警，告警消息刷刷的过来，打开企业微信一看，几乎全部是java应用程序存活的告警，首先先梳理下环境：

当前告警涉及的应用范围是所有通过一个zabbix-proxy代理节点，主机监控、应用监控都是通过该代理节点，上报为zabbix-server端，同事第一时间重启了zabbix-proxy的服务，但并没有效果，仔细观察，都是jvm 不可达的告警【其实到这就应该想到那个zabbix组件的问题了】，主机存活正常，如果是zabbix-proxy节点的问题，那应该相关的主机和应用监控均受影响才对，到此判断zabbix-proxy这个服务正常，而后，开始按一般故障排查流程操作，先看proxy的日志，以前没注意过，这次查看发现很多 cannot send list of active checks to "x.x.x.x": host [xxx-x.x.x.x-xxxx] not found 的信息，以为是这里的问题【后来才知道正常情况下，也是会打印这个信息】，网上查说是别名解析的问题，然后尝试加上hosts解析，其实这思路也不对，因为之前都是好好的，也没添加过hosts解析，所以也排除这个问题，而后，日志提供不了太多的信息，开始查看proxy连接的数据库，是不是有慢sql到这获取的数据异常，也是之前也注意过数据库数据，被现有的结果差点又误导，发现proxy连接的数据库好多表都是空数据，看来，proxy用的表应该不多，而且也不存大量的历史数据，于是这个思路也排除；最后，想想zabbix-proxy的原理吧，忽然注意到还有一个zabbix-java的组件，而这个组件正是负责收集jvm数据的服务，是不是这个服务挂了呢？于是登上服务器，查看这个服务进程也在，端口也在，有点失望，要不重启下这个服务吧【重启大法果然是运维的大招】，发现用自带的shutdown.sh脚本竟然无法停止该服务，而且提升进程不存在，那就有问题了，ps明明可以看到进程，为啥脚本也找不到进程，于是想，进程应该假死了，果断kill掉，执行start.sh脚本，服务正常启动，然后测试下shutdown.sh脚本也能正常关闭，这下，进程应该是正常状态，于是所有关于jvm不可达的报警都逐步恢复。