SpringBoot与MQTT物联网管理平台源码解析与二次开发实践
2026/10/20 9:06:38
接手过几个用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 | 版本太低会启动失败，太高有时会遇到兼容性警告 |
| Orabbix | 1.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/orabbix：
mkdir -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，核心配置长这样：
ZabbixServerList=192.168.10.20 ZabbixServerPort=10051 OrabbixDaemonPort=1521 DatabaseList=orcl@//192.168.10.30:1521/orcl DatabaseList=db2@//192.168.10.31:1521/db2 OraUser=zabbix_mon OraPwd=你的密码逐项说明：
ZabbixServerList：Zabbix Server的IP，多个Server可以用逗号分隔。ZabbixServerPort：Server端接收trapper数据的端口，默认10051。OrabbixDaemonPort：Orabbix自身监听端口。如果只走推送模式，这个端口不一定需要对外开放，但建议保持默认。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 2>&1 &启动后先看进程和日志：
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] Description=Orabbix Oracle Monitor After=network.target [Service] Type=simple User=orabbix WorkingDirectory=/opt/orabbix ExecStart=/usr/bin/java -jar /opt/orabbix/orabbix-1.2.3.jar /opt/orabbix/conf/config.props Restart=always RestartSec=10 [Install] WantedBy=multi-user.target然后执行：
systemctl daemon-reload systemctl enable orabbix systemctl start orabbix这里的User=orabbix建议单独建一个系统账号，别用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_$SGASTAT | Buffer 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核数，或长时间高于50 |
| Buffer 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里仍然要小心。生产环境里，监控方案好不好用的标准，始终是业务稳不稳，而不是图标漂不漂亮。