本篇内容介绍了“Zabbix中Orabbix监控失效的问题实例分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
自从使用了Orabbix监控Oracle以来，很多工作都能够通过这种配置可控的方式处理，有些问题是潜在问题，有些是遗留问题，多多少少还是提高了效率。
最近涉及机房搬迁，我们的Zabbix服务器也在迁移计划中，而因为部署的规模也不大，所以Orabbix和Zabbix Server放在了一起，结果搬迁之后问题就来了，搬迁之后开通了网络防火墙的前提下，系统层面的监控Zabbix Agent表现正常，而原本可用的Orabbix现在没有任何监控信息，
在这种监控基本失效的情况下，我总是不断的收到这样的报警信息,对于一个核心业务而言，这类报警会很敏感，
ZABBIX-监控系统:
------------------------------------
报警内容: Alive xxxx
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: Alive：0
------------------------------------
报警时间:2017.07.21-22:25:40
查看Orabbix的日志信息，发现在连接正常的情况下，最后会抛出一个空指针异常。
[root@orabbx_monitor logs]# tail -f orabbix.log
2017-07-22 23:15:43,168 [main] INFO Orabbix - maxIdleSize=1
2017-07-22 23:15:43,168 [main] INFO Orabbix - maxIdleTime=1800000ms
2017-07-22 23:15:43,168 [main] INFO Orabbix - poolTimeout=100
2017-07-22 23:15:43,168 [main] INFO Orabbix - timeBetweenEvictionRunsMillis=-1
2017-07-22 23:15:43,169 [main] INFO Orabbix - numTestsPerEvictionRun=3
2017-07-22 23:15:43,774 [main] INFO Orabbix - Connected as ORABBIX
2017-07-22 23:15:43,778 [main] INFO Orabbix - --------- on Database -> test
ERROR Orabbix - Error on dbJob for database test QueryList error: java.lang.NullPointerException
INFO Orabbix - Done with dbJob on database testQueryList elapsed time 1089 ms
在这种情况下，分析问题也变得很艰难，因为目前还不知道到底是哪里的问题，到底是Zabbix Server,还是Agent还是Orabbix本身。
这个空指针异常很模糊，通过这些信息，我们基本可以断定Zabbix Server是没有问题的，如果有问题Zabbix Agent的系统监控修直接会失效，而Orabbix的角色有点类似于一个Zabbix AGent,本质上是使用JDBC的方式来发送SQL来达到监控的需求。
所以我的注意力自然而然到了Orabbix上面，首先我把监控的数据库列表精简为一到两个，这样方便排查问题。
经过一番排查，大体的收获就是Zabbix Server端的Zabbix Agent没启动，Orabbix还是需要的。另外一个就是因为服务器搬迁，IP信息发生变化，所以原本的本机的防火墙信息需要补充，比如自己给自己开通10050端口的访问，因为这台服务器是Zabbix Server,也是一台服务器，所以也要监控自己，而Orabbix是需要这个Zabbix Agent的，还有一点也很重要，那就是在/etc/hosts里调整IP信息。
做了这些之后重启Orabbix，发现问题依旧，重启了Zabbix Agent,Zabbix Server，问题依旧。
而且我发现日志信息很简单，开启了Debug模式之后，日志信息虽然多了，但是都是失败的信息，暂时没有发现有价值的信息。
所以我决定通过对比来确定问题的边界。
Orabbix本质上架构虽然简单,官方提供的图形如下：
目前的情况没有进展，数据库层面的监控项都没有生效，所以一个重点的方向就是保证首先Orabbix可用，这个怎么办呢，在当前的环境中调试总是没有进展，那我就干脆重新搭建一套，搭建起来大概10多分钟就搞定了，安装Java,解压orabbix软件包，启动。
数据库和Orabbix的连接信息配置是通过Orabbix里的config.properties文件来控制的，而监控项的信息是通过query.properties来控制的，而在Zabbix里面orabbix的监控项是通过模板来控制的，所以Orabbix的问题分析就主要是通过这三个文件来得到更多的信息。
配置好Orabbix之后，监控项我保留了默认的，发现Orabbix竟然可用了，这就说明config.properties文件没有问题。
而当我把监控项的文件query.properties替换为目前的文件时，启动Orabbix竟然抛出了刚开始的错误，所以可以说明问题出在了query.properties文件上。
那么问题继续如何定位呢，我恢复了query.properties文件之后，监控又恢复了正常，但是我定制了大量的监控项,这些在默认的模板中是没有的，是不是监控模板出了问题呢。
这种情况下，我做了一种中和，那就是使用默认的模板，然后先把一个定制监控项加进去，结果发现这个监控项竟然取不到数据。在Zabbix中错误信息如下：
看起来是数据类型不匹配造成的，我把数据类型改为文本，最后发现这个监控项的输出就是一个空字符，所以转换类型的时候出了问题。
那以前怎么是好的，是不是Orabbix向Zabbix推送数据的时候有问题。监控项是使用Zabbix trapper来推送的，那么我们可以使用zabbix_sender来推送一条信息试试是否成功，比如下面的命令。
./zabbix_sender -z 10.129.xx.xx -p 10051 -s "test" -k db_time -o "test"
info from server: "processed: 1; failed: 0; total: 1; seconds spent: 0.000051"
sent: 1; skipped: 0; total: 1
其中10.129.xx.xx是IP的信息，10051是端口的信息,test是对应的数据库的实例名，也就是对应Zabbix里面的一个主机名，db_time是监控项的名字，最后-o "test"就是发送的信息是test
结果显示这个信息推送还是正常的，那我们就逐步缩小排查范围，基本排除了模板的问题，因为信息推送是没有问题的。
所以一圈排查下来就是query.props文件的问题了，这个空指针的问题看起来很诡异，但是我们可以在这种情况下先折中处理，比如先配置几个优先级很高的监控项，让监控生效，然后在后期对这个监控列表做出很细致的调整。有一点可以确定的是，这个Orabbix自从启动以来就没有停过，所以不排除Orabbix本身的检查机制是否在重启之后有些验证就过不去。
所以我在新服务器上调试成功的Orabbix文件query.properties，在备份之后我就拷贝到了原来的目录下，这样连接信息不变，模板也不变，监控项保留了绝大部分，整个Orabbix的监控又跑起来了。
比如下面的这个DB time监控
“Zabbix中Orabbix监控失效的问题实例分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
