×

扫描二维码登录本站

标签: 暂无标签
本帖最后由 monicazhang 于 2017-8-11 11:22 编辑

自从使用了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的文章,十篇里面有八篇都是我写的,这种情况真是很尴尬,看来只能自己硬着头皮继续分析了。

   目前的情况没有进展,数据库层面的监控项都没有生效,所以一个重点的方向就是保证首先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监控



原创:r13笔记第32天   


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x




上一篇:应如何运用python脚本结合zabbix 监控mongodb
下一篇:Zabbix的安装操作
monicazhang

写了 2297 篇文章,拥有财富 12859,被 21 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by ITIL  © 2001-2025
返回顶部