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的文章，十篇裡面有八篇都是我寫的，這種情況真是很尷尬，看來只能自己硬著頭皮繼續分析了。

   目前的情況沒有進展，資料庫層面的監控項都沒有生效，所以一個重點的方向就是保證首先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監控

  

  

   

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2142430/，如需轉載，請註明出處，否則將追究法律責任。