1. 项目概述为什么需要“专用”Oracle监控搞数据库运维的人应该都有同感Oracle数据库的监控其实是一件挺“膈应”的事。Zabbix本身自带的模板对MySQL、PostgreSQL这种开源库支持得还算过得去唯独对Oracle总是差那么点意思。你能监控到的无非是实例是否活着、主机层面的CPU内存再深一点的等待事件、表空间增长、会话状态、命中率这些东西要么得自己写脚本慢慢磨要么就得靠商业监控软件成本又不低。orabbix这个项目就是专门来解决这个问题的。简单来说它是一套基于Java开发的中间层监控插件作为一个独立的采集服务运行在Zabbix Server和Oracle数据库之间通过JDBC方式连到Oracle用一套内置的SQL去采集数据库的核心性能指标然后把数据推给Zabbix Server。这样一来你不需要在每台数据库服务器上都装Agent也不用自己去写一堆复杂的Shell脚本去解析v$视图导入模板、配好连接信息Oracle的关键指标就能在Zabbix上成体系地展示出来。我用这个项目给生产环境的几套Oracle实例做过监控落地整体跑下来最大的感受就是能用而且比较省心。你说它有多完美那肯定谈不上毕竟开源项目迭代速度跟不上Oracle版本更新的速度但它把DBA最关心的那些指标——会话、等待、表空间、性能负载、物理读写、共享池命中率——都梳理得清清楚楚对日常巡检和故障预警来说完全够用了。这篇文章我会把orabbix的部署踩坑过程、配置细节、以及我在实际运维中积累的一些经验完完整整写出来希望对正在折腾这块的朋友能有点帮助。适合谁看自己维护Oracle环境、又不想在这上面花商业软件预算的运维或DBA同学都可以参考。2. 核心思路拆解它是怎么实现监控的2.1 架构设计中间代理采集模式在正式动手部署之前我建议大家先花十分钟搞清楚orabbix的架构。它不是什么“智能插件”它的工作模式非常直白Zabbix Server ---- Orabbix ---- Oracle数据库实例orabbix其实是一个独立的Java进程你可以把它理解为一道“桥梁”。左边对接Zabbix Server右边通过JDBC连接Oracle数据库。Zabbix Server会定期向orabbix发送“查询请求”orabbix接到请求后执行内置的那一堆监控SQL把结果以文本形式返回给Zabbix。这种设计有个明显的好处Oracle数据库端不需要安装任何额外的东西只要数据库开了监听、有账号能连上去执行查询就行。从安全角度来说这意味着我们只需要给监控账号授最小的查询权限不需要给它DBA权限风险可控。有个细节要注意orabbix并不是通过Zabbix Agent去取数的而是作为一个“外部检查”External Check来工作的它本身也不需要使用Zabbix Agent。所以在你现有的Zabbix架构里只要Server能访问到orabbix所在主机的端口整个链路就能跑通。这对网络层面隔离比较严格的环境是个加分项。2.2 核心监控指标它到底能看什么orabbix内置的监控项覆盖了日常DBA巡检的大部分场景我按模块划分一下模块核心监控项对应视图/表实例状态实例存活、归档模式、数据库版本v$instance会话与锁当前会话数、活动会话数、会话等待、锁等待v$session、v$lock性能负载当前CPU负载、物理读/写、逻辑读、执行次数v$sysstat、v$sgastat等待事件各类等待事件次数与时间v$system_event、v$session_wait表空间表空间大小、已用空间、剩余空间、空间使用率dba_data_files、dba_free_space命中率Buffer Cache命中率、Library Cache命中率v$sysstat、v$librarycacheIO统计数据文件读/写次数、平均读/写时间v$filestat看到这里你应该能明白orabbix的思路就是“把DBA日常看的那些SQL变成了监控项”。它的SQL写得不算特别复杂但胜在覆盖面广而且采集结果会被Zabbix自动归档成历史数据可以随时画趋势图对比数据库某段时间的运行状态。2.3 为什么不用Zabbix原生方案我知道肯定有人想问Zabbix从某个版本开始不是对Oracle做了ODBC支持吗为什么还要多此一举用orabbix这个问题我在选型时也很纠结。Zabbix原生通过ODBC连接Oracle的方案其实配置并不难但它有两个痛点第一它的监控项全部要自己写SQL如果对Oracle的v$视图不熟光是摸索要监控哪些指标、怎么写SQL、怎么处理特殊返回格式就得耗掉不少时间第二Zabbix原生ODBC方式在采集多实例时管理起来比较繁琐每个实例都要单独配置一个监控项组。orabbix则是把常用监控项都固化成了一套模板防呆设计做得好导入模板后基本不用大改就能直接看到数据这一点对快速落地帮助很大。当然orabbix也有自己的短处比如它支持的Zabbix版本有限Java进程本身如果挂掉监控会静默中断。所以我在生产环境里的建议是把它作为主要监控手段之一但不要完全替代数据库自身的告警日志和自定义脚本多一层保障总归稳妥些。3. 部署环境准备与版本选型3.1 版本兼容最容易踩的第一个坑orabbix这个项目最大的历史包袱就是版本兼容性问题。它本质上是一个Zabbix 2.x时代火起来的项目后续虽然有一些社区维护版本但对Zabbix 4.0以上的兼容性还是要格外小心。结合我自己的实践经验给出一个相对稳妥的搭配组合组件推荐版本说明Zabbix Server4.x兼容性最好模板导入不容易出问题Oracle数据库10g/11g/12c/19cJDBC驱动统一用ojdbc8即可Java环境JDK 1.8兼容性上限新版JDK在运行时可能报错orabbix1.2.3最稳定版本网上资源也最多如果你现在的Zabbix是5.0以上版本也不用太担心。orabbix的Java采集端在较新版本上基本也能跑主要是模板导入时可能出现格式兼容问题稍后我会讲怎么处理。但如果你有选择空间我建议还是用一个独立的小版本Zabbix来承载Oracle监控避免升级Zabbix主版本时把监控链路弄崩。3.2 前置准备JDK、驱动、目录规划orabbix运行需要Java环境这个没什么好说的直接用JDK 1.8往外发。我自己用的是jdk-8u202跑得很稳。新版JDK没有特别验证过就不推荐大家去当小白鼠了。然后是JDBC驱动如果你要监控的Oracle版本跨度比较大的话ojdbc8是兼容性最好的选择能适配Oracle 11g到19c的所有版本。驱动包直接拷贝到orabbix的lib目录下面即可。还有一点容易被忽略orabbix所在主机到Oracle数据库的网络连通性以及防火墙是否放行了Oracle的1521端口。我遇到过部署完了一切配置看起来没问题结果orabbix日志里全是Io exception: The Network Adapter could not establish the connection排查到最后才发现是新主机没加防火墙白名单。所以说先拿telnet 数据库IP 1521验证一下基础连通性再继续后续步骤能省下不少排查时间。4. 部署实操一步步把orabbix跑起来4.1 获取安装包与目录规划orabbix的源码包可以从GitHub上找到这里就不贴具体地址了搜orabbix就能出来。下载下来是一个zip压缩包解压后你会看到conf、lib、log、sbin这些目录。整个工具是免安装的解压就能用。我习惯把orabbix放在/opt/orabbix目录下这样路径清晰后续写启动脚本也方便。你解压完要确认lib目录下有没有ojdbc8.jar没有的话把下载好的驱动拷贝进去并给它一个检查确保文件权限为644。提示解压后立刻检查文件编码。orabbix的配置文件在Windows下编写的话编码可能是GBK在Linux下运行会出现乱码。我直接用file命令检查如果是GBK就转为UTF-8转换方式iconv -f GBK -t UTF-8 orabbix/config/config.props config.props.tmp然后再覆盖回去。4.2 数据库端准备创建监控账号orabbix官方文档给的建账号脚本一上来就给了一堆权限甚至在老版本里能看到DBA角色的影子。这个做法在生产环境绝对不能接受。我们需要的是一个能查询性能视图的账号不需要DBA权限。我实际用的授权脚本是这样的CREATE USER ORABBIX IDENTIFIED BY 你的复杂度密码; GRANT CONNECT TO ORABBIX; GRANT CREATE SESSION TO ORABBIX; GRANT SELECT ON V_$INSTANCE TO ORABBIX; GRANT SELECT ON V_$SESSION TO ORABBIX; GRANT SELECT ON V_$SYSSTAT TO ORABBIX; GRANT SELECT ON V_$SYSTEM_EVENT TO ORABBIX; GRANT SELECT ON V_$SGASTAT TO ORABBIX; GRANT SELECT ON V_$LOCK TO ORABBIX; GRANT SELECT ON V_$PARAMETER TO ORABBIX; GRANT SELECT ON V_$FILESTAT TO ORABBIX; GRANT SELECT ON DBA_DATA_FILES TO ORABBIX; GRANT SELECT ON DBA_FREE_SPACE TO ORABBIX;不要觉得权限给得少会影响监控效果orabbix内置的采集SQL查询的核心就是上面这几个视图。如果你想让它采集更多自定义指标再按需补充授权即可。最小权限原则在数据库监控上一样成立。有一点要特别提醒v$视图其实是v_$的同义词授权时直接用V_$开头的底层视图来授别只授同义词的权限否则在部分Oracle版本上会报ORA-00942: table or view does not exist这个坑我踩过一次印象很深。4.3 修改config.props配置orabbix的核心配置在conf/config.props文件里首次运行前必须改对。下面这个是我在生产环境验证过的配置结构你要根据实际环境替换对应项# 数据库连接池相关 ZabbixServerList192.168.1.100 ZabbixServerPort10051 ZabbixServerMaxActive10 # 采集线程设置 OrabbixDaemon.Threads10 # 监控的数据库实例列表 DatabaseListORCL,ORCL2 # 每个实例的具体连接参数格式为 实例名.* ORCL.Urljdbc:oracle:thin://192.168.1.20:1521/ORCL ORCL.Userorabbix ORCL.Password你的密码 ORCL.MaxActive10 ORCL.Enabletrue ORCL2.Urljdbc:oracle:thin://192.168.1.21:1521/ORCL2 ORCL2.Userorabbix ORCL2.Password你的密码 ORCL2.MaxActive10 ORCL2.Enablefalse这里有几个细节值得多说一句ZabbixServerList配置项10051是Zabbix Server监听Agent数据的默认端口。orabbix把数据发到这个端口相当于模拟了一个Agent主动上报数据。如果你改了Zabbix Server的端口这里要跟着改。DatabaseList里配置的实例名我这里举例用的ORCL,ORCL2必须和下面具体配置前缀一一对应大小写要完全一致否则会报找不到配置项。Enabletrue表示启用该实例的采集false则是停用。我常在迁移测试时先用false把新实例加进去确认配置没问题再打开可以避免误报数据干扰现有监控。4.4 启动与验证配置修改完以后先手动启动看一下日志输出cd /opt/orabbix java -jar orabbix-1.2.3.jar -c config/config.props正常情况下你能在命令行里看到类似Start success或Orabbix is running的输出日志文件在log/orabbix.log里会持续滚动。我建议观察两分钟确认日志里没有异常堆栈再把它放到后台或者做成systemd服务。做成systemd服务的话可以参考这个简单的unit文件[Unit] DescriptionOrabbix Oracle Monitor Afternetwork.target [Service] Typesimple Useroracle WorkingDirectory/opt/orabbix ExecStart/usr/bin/java -jar /opt/orabbix/orabbix-1.2.3.jar -c /opt/orabbix/config/config.props Restartalways RestartSec10 [Install] WantedBymulti-user.target提示orabbix进程如果异常退出Zabbix端不会有任何告警只会显示“数据长时间未更新”。所以务必设置Restartalways再配一个额外的外部检查脚本定期检测orabbix进程是否存在双保险。5. Zabbix端配置模板导入与权限处理5.1 导入模板orabbix压缩包里的template/Orabbix_Template.xml就是给Zabbix用的监控模板。这个文件在Zabbix 4.x版本里导入基本不会报错但到了5.0以上版本经常会提示“导入失败”或者某些监控项被跳过。我用Zabbix 5.0导入踩过一次坑报错信息大概是Invalid parameter /items/...: unknown value原因是模板里的某些值域在新版本里已经变了。解决办法有两种方法一把Zabbix模板里的value_type字段值手工修改成新版支持的枚举值。方法二在Zabbix Server上先创建一个老版本的临时环境导入模板后用Configuration - Hosts - Template方式导出再导入新版本环境。我在实际处理时用的是方法二看起来绕了一点但胜在不用去深究模板XML里每个字段的兼容性几秒钟就能完成转换。5.2 创建主机并关联模板模板导入成功后去Zabbix前端创建一个新主机主机名称随意比如Oracle-生产1。关键步骤是在模板选项卡里把orabbix模板关联上去。宏定义里配置{$ORACLE_NAME}值是你在config.props里定义的那个实例名比如ORCL。这一步是最容易出错的地方。orabbix模板里的监控项是通过宏{$ORACLE_NAME}来指定要查哪个数据库实例的。如果你在这里没配置宏或者宏的值和config.props里的实例名对不上监控项会一直处于“不支持”状态显示“No connection could be made to the database”之类的错误。我举个具体例子帮助理解。Zabbix Server接收到orabbix上报的数据时数据里会带着实例ID。前端模板通过宏告诉Zabbix我要展示ORCL这个实例的数据。如果宏没配对Zabbix找不到对应数据自然就“不支持”。所以这个宏一定要检查两遍确保大小写和配置完全一致。5.3 验证数据流配置完成后等上几分钟去主机的最新数据页面看监控项是否开始出数据。正常的话你会看到Running Sessions、Physical Reads、Tablespace Used这些指标开始跳动。如果发现某些监控项还是“不支持”不要慌优先去Zabbix Server的日志/var/log/zabbix/zabbix_server.log里查原因。最常见的情况有三种权限没有授够Oracle返回ORA-00942日志里会直接看到SQL和错误码对着SQL把缺失的视图权限补上就行。宏不匹配模板里明明配置了但前端主机宏被继承关系覆盖了在前端主机详情里重新填一遍。JDBC驱动类加载失败检查lib目录里驱动包和Java版本匹配度。6. 常见问题排查与排障实录6.1 Orabbix进程正常但监控无数据这是我被问得最多的一个问题也是我在排障中遇到最多的故障模式。第一步先看orabbix日志。如果日志里连续出现ERROR 2019-05-20 10:00:01,123 [pool-5-thread-5] Oraxdb - Connection error: Io exception: The Network Adapter could not establish the connection这说明orabbix连不上Oracle。按顺序排查数据库监听是否正常lsnrctl status、防火墙本机和数据库服务器两侧、JDBC URL的端口和SERVICE_NAME是否写对。如果日志里干干净净什么异常都没有那大概率是Zabbix Server端没收到数据。去Zabbix Server上看zabbix_server.conf里ListenPort的配置确认是10051并检查orabbix配置文件里的ZabbixServerList指向的IP端口是否匹配。没有配置正确的IPv6/IPv4绑定策略的话也可能出现连接不上的情况。如果上面都正常再检查模板的Type是不是External Check类型key是否匹配。老版本orabbix的External Check key有严格的格式要求新版本Zabbix对它做了些改动也有可能出现不兼容。6.2 表空间使用率数值异常在一次巡检中我发现某套环境表空间使用率显示为95%以上但数据库实际使用率只有60%左右预警机制基本失灵。排查后发现orabbix的表空间使用率公式是基于dba_data_files和dba_free_space计算的用的是所有数据文件的总和。这里面有一个坑如果你用了Oracle的自动扩展数据文件AUTOEXTEND ONdba_data_files里的bytes是当前文件大小不是最大大小。如果一个表空间拥有多个自动扩展的数据文件orabbix算出的“总大小”可能偏小使用率会偏高。解决方案有两种我自己是用方案二来处理的第一种定期手动收缩数据文件不推荐生产环境风险大。第二种在SQL层面做修正——修改orabbix模板里表空间相关监控项的自定义SQL加入MAXBYTES和AUTOEXTENSIBLE的判断逻辑网上有人分享过修复版SQL可以参考着改。6.3 历史数据无趋势图Zabbix前端能看到监控项的最新数值但趋势图里一直是空白这是因为模板里监控项的history和trends参数配置的保留周期不对。解决办法很简单在Zabbix前端编辑监控项把History retention period和Trend retention period设置成你期望的时间长度比如历史保留7天趋势保留365天。改完后新上报的数据就会自动开始累积历史趋势了。已经过去的数据不会补录这个没办法只能往后慢慢积累。6.4 多实例采集互相干扰orabbix支持多实例采集配置多个DatabaseList条目就可以。但在实际使用中有个细节多个实例的监控数据上报到Zabbix后如果它们使用的{$ORACLE_NAME}宏值不同理论上不会互相干扰。但如果你在模板里又用了另外的宏比如{$ORACLE_PORT}、{$ORACLE_HOST}那就有可能因为宏取值不同导致某些监控项取不到数据。我的建议是多实例环境一个实例对应一个独立的主机主机级宏各自维护不要共享模板级宏尽量避免宏冲突。7. 总结一下我的踩坑心得orabbix这个工具放在今天来看确实有点“老态”但它的监控模型设计得其实挺聪明的把Oracle数据库的核心指标体系梳理得条理清晰对于不想折腾复杂方案的团队来说是个性价比很高的选择。如果你看完这篇文章准备动手部署我有几条实操中的体会可以直接“抄作业”第一把orabbix部署在一台单独的机器上不要和Zabbix Server挤在一起。Java进程吃内存不小和Zabbix Server共用一台机器很容易在数据量大时相互影响。第二监控账号单独创建密码不要和业务账号混用。orabbix的密码是明文存在config.props里的别用太高权限的账号如果可能定期轮换密码改完密码记得重启orabbix进程。第三配置好以后一定要快速验证几类关键监控项的数据准确性比如表空间使用率、会话数、物理读写等顺手比对一下实时查询的值。不要等到告警触发后才怀疑数据不对。第四在Zabbix里另外建一个简单的“心跳监控”监控orabbix本身是否存活——最直接的办法就是在orabbix主机上通过外部检查执行一个脚本检测Java进程或者监控orabbix日志文件的新鲜程度。这个是为orabbix进程异常退出准备的“救生圈”别省。还有一个小技巧orabbix日志会不断累积最好加上logrotate定时切割不然日志文件会无限膨胀占满磁盘。很多小问题都是日志把磁盘塞满后才暴露出来的提前做好日志治理能少半夜爬起来处理故障。最后说一点关于未来的考虑。如果你已经在用orabbix跑Oracle监控它的核心价值并不是让你“有一个监控界面”而是帮你把数据库的运行态势沉淀成历史数据。积累一段时间后你会慢慢掌握数据库的性能基线和趋势规律哪些时段负载高、哪些SQL值得优化、表空间增长节奏怎么样都会有更清晰的认知。我觉得这才是监控系统真正的意义所在——不是事后看告警而是事前有数。