★ FEATURED ARTICLE 接手过几个用Zabbix监控Oracle的项目后我对数据库监控这件事特别有感触实例明明还活着业务已经被会话阻塞拖到卡死表空间涨到95%没人发现等告警响起来DBA连做扩展都要靠运气。后来在Zabbix环境里跑通Orabbix 1.2.3这套方案才把这些风险一个个补上。如果你当前正用Zabbix又恰好需要盯Oracle这篇文章应该能帮你少走很多弯路。这篇文章不打算只贴几条命令而是想把方案背后的思路、配置时的坑、数据从Oracle流转到Zabbix图表的完整链路都讲清楚。适合刚接手的同学也适合已经部署过但监控项不生效、想系统排查问题的朋友。1. 为什么用Orabbix监控Oracle先想清楚再动手1.1 常规监控路径的短板提到Oracle监控很多人第一反应是写脚本让Zabbix Agent定时执行一个sqlplus命令把结果解析出来回传给Server。这个思路在实验环境没问题生产环境却很让人头疼。每次采集都要新起一个sqlplus进程短则两三秒、长则十几秒数据库连接频繁建立和销毁。监控项一多比如要盯表空间、会话数、命中率、归档频率脚本数量直接翻倍。服务器上到处散落着shell脚本和临时文件日志一乱起来连维护的人都分不清哪个脚本在干什么。另一种方式是用Zabbix自带的ODBC监控。功能上没问题但配置成本高要装ODBC驱动、配数据源还要手工写SQL查询模板基本得自己从零搭建。对大多数场景来说投入产出比并不划算。商业监控工具另说价格和部署复杂度往往会劝退很多团队。1.2 Orabbix的工作方式一条JDBC连接做完全部事Orabbix是一个Java守护进程它通过JDBC连接到Oracle数据库。启动后它会周期性执行一批预设的SQL从V_$SYSSTAT、V_$SESSION、DBA_TABLESPACES这些动态性能视图和字典视图里取数然后把结果发送给Zabbix Server。这个过程最大的优势在于连接复用。Orabbix只维护少量JDBC连接采集几十上百个指标都走这些长连接不再频繁建连拆连。对Oracle来说这种采集方式相当温和。数据传递上Orabbix通常采用trapper模式Orabbix主动把采集结果发到Zabbix Server的10051端口模板里的监控项也大多定义为Zabbix trapper类型。这个架构的好处是Zabbix Server不需要反向去连数据库的1521端口。如果数据库网段和监控网段之间有严格的防火墙策略只要放行数据库服务器到Zabbix Server的出站方向即可运维协调起来省心很多。1.3 适用场景和边界这套方案适合中小规模、实例数量不算夸张的环境比如几套到十几套Oracle库版本集中在10g到19c之间。单实例部署最省事RAC环境则需要把各个实例分开配置而且要让数据库账号能访问到相关视图。说实话Orabbix 1.2.3毕竟是有些年头的项目指望它在Oracle 12c之后的多租户架构里面面俱到不现实。CDB里通过DBA_TABLESPACES看到的表和PDB看到的往往不是一回事。如果生产环境大量使用PDB建议先做小范围验证再决定要不要全量铺开。另外如果你们有上百套实例需要统一纳管单跑一个Orabbix进程很容易成为瓶颈这时候可以考虑多实例拆分或者直接评估Zabbix Agent 2自带的ODBC方案。2. 部署准备环境和账号是成败关键2.1 环境要求和版本匹配部署前先把软件环境列清楚省得中途卡壳。组件要求说明Java运行环境JRE 1.6及以上建议1.8版本太低会启动失败太高有时会遇到兼容性警告Orabbix1.2.3目前社区下载仍能获取到JDBC驱动包内置ojdbc14.jar轻版本建议替换具体替换方案见下文Oracle版本常见10g到19g均可12g开始要多关注PDB场景Zabbix Server常见3.x到6.x老版本模板在新版前端导入后需检查网络方面只关心两条链路一是运行Orabbix的机器到Oracle监听端口默认1521必须畅通二是同一台机器到Zabbix Server的10051端口必须畅通。注意这里不是要求Zabbix Server能连数据库而是Orabbix能同时访问数据库和Zabbix Server就行。很多部署资料会提到在zabbix_server.conf里配置StartJavaPollers这通常出现在采用被动模式、由Zabbix Server主动来拉取数据的方案中或者你的Zabbix Server本身还要采JMX指标。如果你和我一样使用默认的trapper推送方式先确认10051端口能通Java Poller的事可以后面再按实际需求开。2.2 数据库监控账号少踩授权的坑Orabbix需要一个数据库账号来跑采集SQL。强烈建议单独建一个专用账号不要拿业务账号或者sysdba去怼。原因很简单职责隔离、权限可控、出问题容易定位。以用户zabbix_mon为例在数据库里执行下面这些授权CREATE USER ZABBIX_MON IDENTIFIED BY 你的强密码; GRANT CONNECT TO ZABBIX_MON; GRANT SELECT ON V_$INSTANCE TO ZABBIX_MON; GRANT SELECT ON V_$SYSSTAT TO ZABBIX_MON; GRANT SELECT ON V_$PARAMETER TO ZABBIX_MON; GRANT SELECT ON V_$SESSION TO ZABBIX_MON; GRANT SELECT ON V_$PROCESS TO ZABBIX_MON; GRANT SELECT ON V_$SGASTAT TO ZABBIX_MON; GRANT SELECT ON V_$TEMPSEG_USAGE TO ZABBIX_MON; GRANT SELECT ON V_$LOG TO ZABBIX_MON; GRANT SELECT ON V_$ARCHIVED_LOG TO ZABBIX_MON; GRANT SELECT ON DBA_DATA_FILES TO ZABBIX_MON; GRANT SELECT ON DBA_TEMP_FILES TO ZABBIX_MON; GRANT SELECT ON DBA_FREE_SPACE TO ZABBIX_MON; GRANT SELECT ON DBA_TABLESPACES TO ZABBIX_MON;注意视图名用的是V_$带下划线不是V$。这是Oracle动态视图的底层结构JDBC查询时区分大小写漏掉下划线会导致授权不生效。这个问题我一开始就踩过日志里不断蹦出ORA-00942: table or view does not exist排查半天才发现授权语句写错了。还有一件事必须提前处理Oracle的DEFAULT用户Profile默认有密码有效期限制。很多库是180天也有的是90天。给Orabbix用的账号如果到期采集就会无声无息地断掉表现是监控图表突然不再更新日志里也只有连接失败信息。建议建号时直接改掉该账号对应的Profile限制或者想办法做密码到期提醒否则半夜被监控数据不动报警叫起来是迟早的事。3. 部署与配置Orabbix 1.2.3完整实操3.1 解压、替换驱动、改配置先把安装包放到目标目录解压到/opt/orabbixmkdir -p /opt/orabbix unzip orabbix-1.2.3.zip -d /opt/orabbix进去看一眼目录结构重点记住这几个地方conf/config.props主配置文件lib/依赖的jar包包括JDBC驱动log/运行日志目录templates/Zabbix前端需要导入的模板文件run.sh启动脚本包内置的JDBC驱动通常是ojdbc14.jar。如果你的Oracle版本较新比如12c以后的库建议把它换成对应版本的驱动。我习惯把ojdbc8.jar放到lib/目录下并移除或改名旧驱动然后重启Orabbix。这个步骤能解决很多莫名其妙的连接超时和驱动不兼容报错。接着打开conf/config.props核心配置长这样ZabbixServerList192.168.10.20 ZabbixServerPort10051 OrabbixDaemonPort1521 DatabaseListorcl//192.168.10.30:1521/orcl DatabaseListdb2//192.168.10.31:1521/db2 OraUserzabbix_mon OraPwd你的密码逐项说明ZabbixServerListZabbix Server的IP多个Server可以用逗号分隔。ZabbixServerPortServer端接收trapper数据的端口默认10051。OrabbixDaemonPortOrabbix自身监听端口。如果只走推送模式这个端口不一定需要对外开放但建议保持默认。DatabaseList每个需要监控的数据库一行格式是别名JDBC连接字符串。这里orcl就是别名后面是标准的JDBC thin连接写法。OraUser和OraPwd数据库监控账号和密码。这里有一个全网教程都容易忽略的关键点DatabaseList里的别名必须和你在Zabbix前端创建的主机名完全一致。比如这里写了orcl前端主机名也必须是orcl否则Orabbix把数据推过去Zabbix不知道发给谁监控项里全是No data。这个坑我见过太多次了。3.2 启动Orabbix并验证进程配置完成后先简单验证Java环境java -version然后用脚本启动cd /opt/orabbix ./run.sh如果希望日志不被终端占用可以这样nohup java -jar orabbix-1.2.3.jar conf/config.props log/console.log 21 启动后先看进程和日志ps -ef | grep orabbix tail -f /opt/orabbix/log/orabbix.log正常日志里会出现采集任务启动、数据库连接成功之类的内容。如果上来就是连接失败先不要急着怀疑Orabbix去检查三件事数据库监听是否起来了、JDBC连接串写没写对、网络到1521端口是否通。按这个顺序排查比漫无目地改配置快得多。如果在日志里看到Could not connect这类错误还有个很常见的隐蔽原因JDBC驱动版本和数据库版本不匹配。前面提到的替换驱动步骤往往就是这里的解药。3.3 把Orabbix做成系统服务生产环境里我不太建议只挂着nohup就跑。服务器一重启Orabbix不会自动起来监控就会缺一大段数据。可以写一个简单的systemd服务比如/etc/systemd/system/orabbix.service[Unit] DescriptionOrabbix Oracle Monitor Afternetwork.target [Service] Typesimple Userorabbix WorkingDirectory/opt/orabbix ExecStart/usr/bin/java -jar /opt/orabbix/orabbix-1.2.3.jar /opt/orabbix/conf/config.props Restartalways RestartSec10 [Install] WantedBymulti-user.target然后执行systemctl daemon-reload systemctl enable orabbix systemctl start orabbix这里的Userorabbix建议单独建一个系统账号别用root跑。用root跑Java进程一旦出安全问题影响范围太大这个习惯不管在哪个监控项目里都适用。4. Zabbix侧接入模板导入和数据链路确认4.1 导入模板Orabbix安装包的templates/目录下有一个XML模板文件文件名因打包版本略有差异导入后你会看到类似Orabbix的模板出现在模板列表里。登录Zabbix前端进入数据采集-模板点右上角导入选择那个XML文件。如果Zabbix版本较新导入时可能会提示某些字段不兼容。不用慌通常直接按默认导入就能成功。导入后检查模板里的监控项如果大部分类型是Zabbix trapper说明数据流是Orabbix主动推送和前面的配置思路一致。4.2 创建主机并关联模板进入数据采集-主机创建一台主机。主机名称必须和config.props里DatabaseList的别名一致。比如配置里写的是orcl//...前端这一个监控主机就叫orcl。主机加入某个主机组然后找到刚才导入的Orabbix模板点链接。这个环节不需要给主机填Agent IP也不需要配置Agent端口。因为这些监控项走的是trapper通道不是Zabbix Server主动去拉取。4.3 三个检查点确认数据链路模板也导了、主机也建了数据却没出来按下面三个检查点依次确认第一检查点Orabbix进程里对应数据库的任务是否在跑。看/opt/orabbix/log/orabbix.log里面应该有针对orcl的采集循环记录。第二检查点网络方向是否放行。在运行Orabbix的机器上执行telnet 192.168.10.20 10051能通才算过关。第三检查点前端主机名是否和别名一致。这个看起来简单实际出错率极高。确认完之后去监测-最新数据筛选主机orcl。如果能看到监控项的最新值在刷新链路就算跑通了。数据采集频率上Orabbix默认按模板设定的周期进行。你会在监控项里看到一些项更新间隔在60秒左右一些表空间类项可能更长。真要追求秒级响应的话建议不要调太激进毕竟每次采集都会对数据库产生一定的查询负载监控本身不该喧宾夺主。5. 核心监控指标与告警阈值推荐5.1 必须盯的几类指标Orabbix模板里的监控项不少但真正值得放进仪表盘和告警规则里的可以分成四个维度分类数据来源主要关注点可用性V_$INSTANCE实例状态、启动时间、限制模式容量DBA_TABLESPACES、DBA_FREE_SPACE表空间已用、剩余、使用率会话与锁V_$SESSION、V_$PROCESS总会话数、活跃会话数、进程数性能与命中率V_$SYSSTAT、V_$SGASTATBuffer Cache命中率、Library Cache命中率、物理读、事务数容量维度最容易被人盯死但我想提醒一点表空间使用率是存量视角自动扩展的Datafile是变量视角。如果数据文件设置了AUTOEXTEND ON使用率看着不高实际文件已经快撑到MAXSIZE了这才是真正的隐患。Orabbix这类模板一般不会帮你把MAXSIZE和剩余扩展空间也算出来所以有条件的话建议围绕DBA_DATA_FILES的BYTES和MAXBYTES字段做补充监控。性能维度的命中率初看觉得越低越危险实际要结合业务特性看。一个频繁全表扫描的分析型库Buffer Cache命中率低是常态。与其拿一个网传的95%标准去套所有库不如先把一周的基线数据采下来再定义合理的上下界。5.2 告警阈值怎么给下面这组阈值是我在项目里用过的基础版本拿过去用的时候务必按实际业务调整监控对象建议告警级别阈值参考实例状态灾难Status不为OPEN即告警表空间使用率警告超过85%表空间使用率高紧急超过95%当前总会话数警告超过基线值1.5倍或绝对值300活跃会话数高紧急超过CPU核数或长时间高于50Buffer Cache命中率高紧急低于92%持续10分钟Library Cache命中率警告低于95%持续10分钟归档日志生成速率警告短时间持续飙升结合磁盘空间看特别强调会话数阈值。不要只设一个固定值不同核心库的会话基线能差出好几倍。刚开始可以设一个宽松的固定值比如500运行两周后看图表里的P90值再用这个值去校准。告警通知渠道上Zabbix的媒介配置里把钉钉、企业微信、邮件接好以后记得给每个触发器设好恢复表达式。我见过很多团队只设了告警没设恢复结果问题处理完故障一直挂在屏幕上后面真出大事时告警反而被淹没。6. 常见问题与排查技巧实录6.1 监控项长期无数据先查哪里这是Orabbix使用中排名第一的问题。现象很统一最新数据里一堆监控项时间列永远是空的或者显示No data。排查顺序我建议固定下来别乱跳先看Orabbix进程在不在ps -ef | grep orabbix。再看日志最后几十行tail -50 /opt/orabbix/log/orabbix.log。确认数据库账号密码还能不能登录比如用sqlplus手动连接一次。检查Zabbix Server的10051端口通不通。核对前端主机名和DatabaseList别名是否一致。看模板里监控项的Type是不是Zabbix trapper。按这个顺序走下来90%的问题都能定位。剩下来那些十有八九是驱动版本和Oracle版本不匹配。6.2 数据库连不上驱动和配置的双重陷阱Orabbix日志里出现Could not connect或Connection refused时先确认基础网络。如果网络没问题大概率是下面两个原因之一第一JDBC连接串写错了。jdbc:oracle:thin://主机:1521/服务名这套格式里服务名不是SID很多人把SID填到服务名位置自然连不上。不确定服务名的话在数据库服务器上执行lsnrctl status里面输出里能找到Service名称。第二驱动版本太老。Oracle 12c以后的库还抱着ojdbc14.jar不放经常出现握手失败或版本不支持的报错。换成高版本驱动后大部分问题能直接消失。6.3 账号密码过期了处理完之后要重启如果你发现某个库的监控数据停在了同一时间戳去数据库看一眼账号状态常见的报错是ORA-28001: the password has expired。处理方法是重置密码然后授权依然存在ALTER USER ZABBIX_MON IDENTIFIED BY 新密码;这里最容易漏掉的动作是重启Orabbix进程。因为config.props里的OraPwd还是旧密码只重置数据库不更新配置下次采集照样连不上。正确的流程是改密码更新配置文件重启Orabbix服务再确认日志恢复正常。6.4 表空间监控不准多半是autoextend和多租户有朋友会遇到这种情况SQL查出来表空间使用率38%Zabbix图表里却显示78%两边对不上。原因一般在DBA_FREE_SPACE和Datafile的MAXSIZE计算口径上。如果Datafile设置的是AUTOEXTEND ON使用率有两种算法按当前文件大小算和按最大可扩展大小算。Orabbix模板里默认按哪个口径不同版本有差异。建议以数据库实际文件大小为准去对齐并额外关注Maxsize。不要看见显示异常就怀疑Orabbix坏了很可能是计算口径差异。至于多租户架构CDB里看DBA_TABLESPACES和普通库看的结果不一样部分指标在容器库视角下会失真。如果你监控的是PDB建议在PDB里单独建监控账号并单独配置连接串不要在CDB级别偷懒。6.5 Zabbix版本升级后的模板兼容升级Zabbix Server后导入的旧模板可能出现某些字段损坏监控项在最新数据里点开报错。我的处理习惯是升级前先导出模板备份升级后在测试环境重新导入并验证。遇到模板导入报错多数情况是因为旧模板使用了不兼容的键值把对应监控项删掉重新建比强行改XML格式更省时间。7. 生产环境使用后的几点体会Orabbix这套方案我用了不短时间总体评价是轻量、实用、坑清楚。它不需要你在数据库上装一堆Agent组件也基本不用改业务表结构对于监控三板斧——可用性、容量、性能已经覆盖得很到位。但有几个长期维护的细节我想特别提醒监控账号的生命周期管理要纳入日常。长期跑着的监控账号如果只是建号时设置好密码就再也不管总有一天会在不合适的时机失效。建议把所有监控账号统一登记建号时就设置密码过期提醒或者直接调整Profile让该账号密码长期有效但前提是密码本身足够复杂并且只给监控使用。日志文件记得做轮转。Orabbix的log/目录会随着运行持续增大如果不处理时间长了会占满磁盘。我习惯在系统里加一个logrotate配置让orabbix.log按天轮转保留7到14天即可。配置文件的备份也别忽略。config.props里包含数据库列表、监控账号等关键信息平时改动不大但一旦机器故障要重建没有备份就得靠记忆重新搭一套。把它纳入运维配置管理是成本极低、收益很高的一件事。另外如果团队已经在用Zabbix Agent 2并且有人力愿意维护自定义模板ODBC方案也值得尝试。Agent 2的原生性能更强、数据采集更稳定但模板建设需要投入。Orabbix的优势在于成熟、现成、上手快。两者不是非此即彼的关系很多时候可以先上Orabbix解决眼前问题再逐步把核心库迁移到更现代的采集方案。最后说一个我个人的小习惯每次上线新的Oracle监控项我都会在数据库端观察一周的负载变化确认监控查询没有带来明显的性能影响。Orabbix的连接复用已经做得很温和但表空间发现规则这类需要扫描大量字典视图的查询在高版本Oracle里仍然要小心。生产环境里监控方案好不好用的标准始终是业务稳不稳而不是图标漂不漂亮。
阅读完成 · 觉得有帮助？
