淺談Orabbix監控指標

對於Orabbix監控Oracle來說，它是提供了一個相對輕量級的客戶端來綜合監控多個資料庫例項。從這一點來看，它的角色有點類似於工作中使用的SQLDeveloper或者toad這類的工具。
在之前的章節中，先花了些篇幅去比較zabbix和grid control,其實從功能上來看，基於zabbix的Orabbix的監控功能要有限的多。提供的預設模板中，監控觸發器不到20個。
自己梳理了一下，預設的監控觸發器在15個左右。

故障型別	報警對應項	錯誤型別	報錯簡述
資料庫沒有資料響應	Oracle:alive	High	資料庫無資料響應
資料庫例項不可用	Oracle:alive	High	資料庫例項是否可用
資料庫中存在鎖	Oracle:locks	High	資料庫中存在鎖
session使用量過高	(Oracle:session.last(0)}*100/Oracle:maxsession.last(0)})>80	High	session過多，比如session超過80%
Process 使用量過高	(Oracle:procnum.last(0)}*100/Oracle:maxprocs.last(0)})>80	High	process過多，比如process超過80%
異常資訊的通用審計	Oracle:audit	High	異常資訊的審計，比如密碼錯誤次數過多
active session數過高	Oracle:session_active	High	active session數
使用者異常鎖定	Oracle:users_locked	Warning	使用者密碼過期或者錯誤登入次數過多賬戶鎖定
表空間使用率過高	Oracle:showtsps	Warning	表空間使用率超過90%
歸檔日誌量過高	Oracle:archive	Warning	歸檔日誌量
正常執行時間	Oracle:uptime	Average	正常執行情況
PGA 使用量過高	(Oracle:pga.last(0)}*100/Oracle:pga_aggregate_target.last(0)})>90	Average	PGA使用率過高
快取命中率不足	Oracle:hitratio_table_proc.avg(60)}<50|Oracle:hitratio_trigger.avg(60)}<50|Oracle:hitratio_sqlarea.avg(60)}<50|Oracle:hitratio_body.avg(60)}<50	Information	快取命中率不足

在這個基礎上進行了一些額外的補充，比如去檢測dg是否可用，檢測閃回區空間利用率是否合理，監控記憶體使用率是否過高等等。

datagurad不可用	Oracle:dg_error	High	datagurad不可用
剩餘記憶體不足2G	Oracle:vm.memory.size[free].last()}<2048m	Warning	剩餘記憶體不足2G
閃回區使用率過高	Oracle:archive_area_usage	Warning	閃回區使用率過高

其實和實際工作結合起來還有不少的盲點。
比如監聽器的監控
是否有有大量的並行查詢
DB響應時間的監控
ASM的一些基本監控
rac例項的監控
所以把問題以面鋪開來看，還有很多的工作需要做，而不只是侷限於當前的監控指標。
當然了也不能這麼為難orabbix,我相信這個開發者是希望在Oracle的監控上有所突破，但是還是給我們留下了不少的功課去完成。
自己在sourceforge上下載了原始碼，原始碼的實現是基於java,依賴於zabbix基礎工程，程式碼量其實不大，如果能夠在這個基礎上進行深入擴充套件，可能還會有更多的驚喜。
比如目前使用orabbix監控表空間的使用明細，比如在資料庫A中有10個表空間，在資料庫B中有5個表空間，對於表空間的空間剩餘量的監控透過SQL就會是下面的形式。
TS1     5%
TS2     9%
TS3     20%
TS4     30%
比如我們需要監控剩餘比例在10%以內的，那就是說TS1,TS2了。目前的實現是把結果集當做一個text來對待，還不能把結果集中的每一列單獨來處理，所以郵件報警的顯示還是不夠清晰。還得藉助於結果集，然後再次進行指令碼格式化顯示，實現起來還是不夠那麼靈活。這個也是我下一步需要攻關的點。
如果我們較真一下，比較一下gc和orabbix的監控指標，gc裡面有300多個，粒度，數量上遠遠超過了orabbix,但是如果你自己靜下心來，似乎自己常用的指標其實不到10%。
還是選擇適合自己的，滿足工作就可以。