Zabbix中Orabbix监控失败问题实例分析

由于Orabbix是用来监控Oracle的，所以很多任务都可以通过这种配置控制的方式来处理。有些问题是潜在问题，有些是遗留问题，但效率得到了一定程度的提升。

最近，涉及到机房搬迁。我们的 Zabbix 服务器也在迁移计划中。由于部署规模不大，所以Orabbix和Zabbix Server放在一起。结果，搬迁后出现了问题。打开网络防火墙后，系统级监控Zabbix Agent正常执行，但原来可用的Orabbix现在没有任何监控信息离子。

当这种监控基本失效的时候，我总是保留收到这样的报警信息。对于核心业务来说，此类报警会非常敏感。

Zabbix-监控系统：
------------ -------- ------------------
报警内容：Alive xxxx
------------------------ ------ ------------------
警报级别：问题
---------------------------- -------- --------------
监控项：存活：0
---------------- ------- --------------
报警时间：2017.07.21-22:25:40

查看Orabbix，根据日志信息，发现连接正常时，最后会抛出空指针异常。

[root@orabbx_monitor 日志]# tail -f orabbix.log
2017-07-22 23:15:43,168 [main] INFO Orabbix - maxIdleSize=1
2017-07 -22 23:15:43,168 [主要] 信息 Orabbix - maxIdleTime=1800000ms
 2017-07-22 23:15:43,168 [主要] 信息 Orabbix - poolTimeout=100
2017-07-22 23: 15:43,168 [主要] 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 - 连接为 ORABBIX
2017-07-22 23 :15:43,778 [main] INFO Orabbix - --------- 数据库 -> 测试

ERROR Orabbix - 数据库测试的 dbJob 出错QueryList 错误：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的监控项是通过gh模板，所以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"
来自服务器的信息：“已处理：1；失败：0；总计：1；花费的秒数：0.000051"
发送：1；跳过：0； Total: 1

其中10.129.xx.xx是IP信息，10051是端口信息，test是对应数据库的实例名，对应Zabbix中的一个主机名，db_time是监控项名称，最后-o "test"表示发送的信息为test

结果显示信息为正常推。是的，那么我们会逐步缩小排查范围，基本消除模板问题，因为信息推送没有问题。

所以经过一轮排查，问题出在query.props文件上。这个空指针问题看上去很奇怪，但是这种情况我们可以先妥协一下，比如先配置几个优先级。使用高层监控项让监控有效，然后在后期对监控清单进行非常细致的调整。有一件事可以确定的是，Orabbix从启动以来就没有停止过，所以不排除Orabbix自身的检查机制在重启后可能无法通过一些验证。

这样我在新的serverix文件query.properties上成功调试了Orabb，备份后我将其复制到原来的目录中。这样，连接信息不变，模板不变，大部分moni保留项目，整个Orabbix监控再次运行。

比如下面的DB时间监控

《Zabbix中Orabbix监控失败示例分析》内容就是以上就是小编为大家带来的介绍，感谢大家的阅读。如果您想了解更多行业资讯，可以关注网站，小编将为大家输出更多优质实用文章！