Zabbix中Orabbix監(jiān)控失效的問題實(shí)例分析

本篇內(nèi)容介紹了“Zabbix中Orabbix監(jiān)控失效的問題實(shí)例分析”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

   自從使用了Orabbix監(jiān)控Oracle以來，很多工作都能夠通過這種配置可控的方式處理，有些問題是潛在問題，有些是遺留問題，多多少少還是提高了效率。

   最近涉及機(jī)房搬遷，我們的Zabbix服務(wù)器也在遷移計(jì)劃中，而因?yàn)椴渴鸬囊?guī)模也不大，所以O(shè)rabbix和Zabbix Server放在了一起，結(jié)果搬遷之后問題就來了，搬遷之后開通了網(wǎng)絡(luò)防火墻的前提下，系統(tǒng)層面的監(jiān)控Zabbix Agent表現(xiàn)正常，而原本可用的Orabbix現(xiàn)在沒有任何監(jiān)控信息，

   在這種監(jiān)控基本失效的情況下，我總是不斷的收到這樣的報(bào)警信息,對(duì)于一個(gè)核心業(yè)務(wù)而言，這類報(bào)警會(huì)很敏感，

ZABBIX-監(jiān)控系統(tǒng):
------------------------------------
報(bào)警內(nèi)容: Alive xxxx
------------------------------------
報(bào)警級(jí)別: PROBLEM
------------------------------------
監(jiān)控項(xiàng)目: Alive：0
------------------------------------
報(bào)警時(shí)間:2017.07.21-22:25:40

   查看Orabbix的日志信息，發(fā)現(xiàn)在連接正常的情況下，最后會(huì)拋出一個(gè)空指針異常。

[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

  在這種情況下，分析問題也變得很艱難，因?yàn)槟壳斑€不知道到底是哪里的問題，到底是Zabbix Server,還是Agent還是Orabbix本身。

  這個(gè)空指針異常很模糊，通過這些信息，我們基本可以斷定Zabbix Server是沒有問題的，如果有問題Zabbix Agent的系統(tǒng)監(jiān)控修直接會(huì)失效，而Orabbix的角色有點(diǎn)類似于一個(gè)Zabbix AGent,本質(zhì)上是使用JDBC的方式來發(fā)送SQL來達(dá)到監(jiān)控的需求。

   所以我的注意力自然而然到了Orabbix上面，首先我把監(jiān)控的數(shù)據(jù)庫列表精簡(jiǎn)為一到兩個(gè)，這樣方便排查問題。

   經(jīng)過一番排查，大體的收獲就是Zabbix Server端的Zabbix Agent沒啟動(dòng)，Orabbix還是需要的。另外一個(gè)就是因?yàn)榉?wù)器搬遷，IP信息發(fā)生變化，所以原本的本機(jī)的防火墻信息需要補(bǔ)充，比如自己給自己開通10050端口的訪問，因?yàn)檫@臺(tái)服務(wù)器是Zabbix Server,也是一臺(tái)服務(wù)器，所以也要監(jiān)控自己，而Orabbix是需要這個(gè)Zabbix Agent的，還有一點(diǎn)也很重要，那就是在/etc/hosts里調(diào)整IP信息。

   做了這些之后重啟Orabbix，發(fā)現(xiàn)問題依舊，重啟了Zabbix Agent,Zabbix Server，問題依舊。

   而且我發(fā)現(xiàn)日志信息很簡(jiǎn)單，開啟了Debug模式之后，日志信息雖然多了，但是都是失敗的信息，暫時(shí)沒有發(fā)現(xiàn)有價(jià)值的信息。

   所以我決定通過對(duì)比來確定問題的邊界。

   Orabbix本質(zhì)上架構(gòu)雖然簡(jiǎn)單,官方提供的圖形如下：

   目前的情況沒有進(jìn)展，數(shù)據(jù)庫層面的監(jiān)控項(xiàng)都沒有生效，所以一個(gè)重點(diǎn)的方向就是保證首先Orabbix可用，這個(gè)怎么辦呢，在當(dāng)前的環(huán)境中調(diào)試總是沒有進(jìn)展，那我就干脆重新搭建一套，搭建起來大概10多分鐘就搞定了，安裝Java,解壓orabbix軟件包，啟動(dòng)。

   數(shù)據(jù)庫和Orabbix的連接信息配置是通過Orabbix里的config.properties文件來控制的，而監(jiān)控項(xiàng)的信息是通過query.properties來控制的，而在Zabbix里面orabbix的監(jiān)控項(xiàng)是通過模板來控制的，所以O(shè)rabbix的問題分析就主要是通過這三個(gè)文件來得到更多的信息。

   配置好Orabbix之后，監(jiān)控項(xiàng)我保留了默認(rèn)的，發(fā)現(xiàn)Orabbix竟然可用了，這就說明config.properties文件沒有問題。

   而當(dāng)我把監(jiān)控項(xiàng)的文件query.properties替換為目前的文件時(shí)，啟動(dòng)Orabbix竟然拋出了剛開始的錯(cuò)誤，所以可以說明問題出在了query.properties文件上。

    那么問題繼續(xù)如何定位呢，我恢復(fù)了query.properties文件之后，監(jiān)控又恢復(fù)了正常，但是我定制了大量的監(jiān)控項(xiàng),這些在默認(rèn)的模板中是沒有的，是不是監(jiān)控模板出了問題呢。

    這種情況下，我做了一種中和，那就是使用默認(rèn)的模板，然后先把一個(gè)定制監(jiān)控項(xiàng)加進(jìn)去，結(jié)果發(fā)現(xiàn)這個(gè)監(jiān)控項(xiàng)竟然取不到數(shù)據(jù)。在Zabbix中錯(cuò)誤信息如下：

看起來是數(shù)據(jù)類型不匹配造成的，我把數(shù)據(jù)類型改為文本，最后發(fā)現(xiàn)這個(gè)監(jiān)控項(xiàng)的輸出就是一個(gè)空字符，所以轉(zhuǎn)換類型的時(shí)候出了問題。

那以前怎么是好的，是不是Orabbix向Zabbix推送數(shù)據(jù)的時(shí)候有問題。監(jiān)控項(xiàng)是使用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是對(duì)應(yīng)的數(shù)據(jù)庫的實(shí)例名，也就是對(duì)應(yīng)Zabbix里面的一個(gè)主機(jī)名，db_time是監(jiān)控項(xiàng)的名字，最后-o "test"就是發(fā)送的信息是test

結(jié)果顯示這個(gè)信息推送還是正常的，那我們就逐步縮小排查范圍，基本排除了模板的問題，因?yàn)樾畔⑼扑褪菦]有問題的。

   所以一圈排查下來就是query.props文件的問題了，這個(gè)空指針的問題看起來很詭異，但是我們可以在這種情況下先折中處理，比如先配置幾個(gè)優(yōu)先級(jí)很高的監(jiān)控項(xiàng)，讓監(jiān)控生效，然后在后期對(duì)這個(gè)監(jiān)控列表做出很細(xì)致的調(diào)整。有一點(diǎn)可以確定的是，這個(gè)Orabbix自從啟動(dòng)以來就沒有停過，所以不排除Orabbix本身的檢查機(jī)制是否在重啟之后有些驗(yàn)證就過不去。

   所以我在新服務(wù)器上調(diào)試成功的Orabbix文件query.properties，在備份之后我就拷貝到了原來的目錄下，這樣連接信息不變，模板也不變，監(jiān)控項(xiàng)保留了絕大部分，整個(gè)Orabbix的監(jiān)控又跑起來了。

    比如下面的這個(gè)DB time監(jiān)控

“Zabbix中Orabbix監(jiān)控失效的問題實(shí)例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！