在之前的章节中,先花了些篇幅去比较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%。
还是选择适合自己的,满足工作就可以。
http://blog.itpub.net/23718752/viewspace-1770782/