【Zabbix实战】基于ODBC构建企业级Oracle数据库监控体系-育师

1. 为什么选择ODBC来监控Oracle数据库？

大家好，我是老张，在运维圈子里摸爬滚打了十几年，经手过各种数据库监控方案。今天想和大家聊聊一个在企业里特别实用，但很多朋友觉得配置起来有点“劝退”的技术：用Zabbix配合ODBC来监控Oracle数据库。你可能听过用Zabbix Agent、用脚本，甚至用专门的商业插件来监控Oracle，那我为什么还要折腾ODBC呢？这里面的门道，我踩过不少坑，也尝到了不少甜头。

首先，咱们得搞清楚ODBC是个啥。你可以把它想象成一个“万能翻译官”。你的监控系统（Zabbix）说中文（它自己的查询语言），而Oracle数据库说英文（Oracle自己的协议）。直接对话？鸡同鸭讲。ODBC的作用，就是站在中间，把Zabbix的指令精准地翻译成Oracle能听懂的命令，再把Oracle返回的结果翻译成Zabbix能理解的格式。这样一来，Zabbix就能用一种相对标准化的方式，去跟市面上几乎所有的关系型数据库“聊天”了，Oracle、MySQL、SQL Server都不在话下。

那这么做的好处是什么？我总结下来有三点特别实在。第一是标准化。你不用为每一种数据库都去学一套独特的监控代理部署方法，ODBC提供了一套统一的接口。第二是灵活性。监控项完全由你自定义，你想查什么就写什么SQL语句，从简单的表空间使用率，到复杂的会话锁等待、AWR报告里的关键指标，都能轻松抓取。第三是集中管理。当你的Zabbix Server上配置好ODBC驱动后，理论上只要网络通、权限够，你就能监控成百上千个Oracle实例，无需在每个数据库服务器上都安装Zabbix Agent，这在管理大量数据库的环境里，能省下巨大的运维成本。

当然，这条路也不是一马平川。ODBC的配置，特别是Oracle Instant Client的安装、环境变量的设置、连接串的编写，每一步都有细节，一步错了可能就连接不上。但别担心，接下来我会把我这些年趟过的路、踩过的坑，掰开揉碎了讲给你听，保证你跟着做，就能在企业环境里把这套体系稳稳当当地搭起来。

2. 搭建前的环境准备与规划

动手之前，磨刀不误砍柴工。一套稳定的监控体系，离不开清晰的环境规划和前期准备。这里我会分服务器端和数据库端来讲，并且会特别说明CentOS和Ubuntu这两个主流Linux发行版的差异，因为我在混合环境里都部署过，有些坑你提前知道就能避开。

2.1 Zabbix服务器端：驱动安装是基石

无论你的Zabbix是运行在CentOS Stream 8/9还是Ubuntu 20.04/22.04上，第一步都是在Zabbix Server（或者负责监控的Proxy服务器）上安装Oracle Instant Client。这是ODBC连接Oracle的“桥梁”组件。Oracle官方不提供现成的apt或yum仓库（针对最新版），所以我们通常直接下载RPM包来安装。

第一步，创建并进入工作目录。我习惯在根目录下建一个/zabbix目录，把所有相关的东西都放这里，干净利落。

mkdir -p /zabbix cd /zabbix

第二步，下载Instant Client安装包。这里有个关键点：版本匹配。理论上，你的客户端版本应该尽量接近或等于被监控数据库的版本。比如监控19c的库，就用19.x的客户端。去Oracle官网下载需要登录，比较麻烦。我通常直接用wget从Oracle的公开Yum仓库拉取，方便很多。下面以19.22版本为例：

wget https://yum.oracle.com/repo/OracleLinux/OL8/oracle/instantclient/x86_64/getPackage/oracle-instantclient19.22-odbc-19.22.0.0.0-1.x86_64.rpm wget https://yum.oracle.com/repo/OracleLinux/OL8/oracle/instantclient/x86_64/getPackage/oracle-instantclient19.22-sqlplus-19.22.0.0.0-1.x86_64.rpm wget https://yum.oracle.com/repo/OracleLinux/OL8/oracle/instantclient/x86_64/getPackage/oracle-instantclient19.22-basic-19.22.0.0.0-1.x86_64.rpm wget https://yum.client19.22-devel-19.22.0.0.0-1.x86_64.rpm

你需要下载四个包：basic（基础库）、sqlplus（测试连接用）、devel（头文件，编译可能需要）、odbc（核心ODBC驱动）。全下下来就对了。

第三步，安装RPM包。在CentOS/RHEL系系统上，直接用yum localinstall就行，它能自动解决依赖。

yum localinstall oracle-instantclient19.22-*.rpm

安装完成后，可以用rpm -qa | grep oracle和find / -name client64来确认安装位置，通常会在/usr/lib/oracle/19.22/client64。

重点来了：Ubuntu系统怎么办？Ubuntu用的是deb包，不能直接装rpm。这时候就需要一个叫alien的神器，它能把rpm转换成deb。操作顺序是：

# 安装alien转换工具 sudo apt-get install alien # 转换当前目录下所有oracle的rpm包 sudo alien oracle-instantclient19.22-*.rpm # 安装转换后的deb包 sudo dpkg -i oracle-instantclient19.22-*.deb

在Ubuntu上安装后，你很可能遇到一个经典错误：运行sqlplus时提示libaio.so.1: cannot open shared object file。这是因为缺少异步IO库。解决起来很简单：

sudo apt-get install libaio1 # 有时候还需要创建一个软链接 sudo ln -s /usr/lib/x86_64-linux-gnu/libaio.so.1 /usr/lib/libaio.so.1

这个坑我踩过好几次，记住它，能省你不少排查时间。

2.2 数据库服务器端：权限与连接测试

Zabbix服务器这边准备好了“翻译官”，数据库那边得给“翻译官”发一张“通行证”。这张通行证就是一个具有适当权限的数据库用户。我强烈建议专门创建一个用于监控的数据库用户，比如就叫zabbix，而不是直接使用业务账号或高权限账号。

首先，你得确保数据库监听器是正常工作的。登录到你的Oracle数据库服务器，用oracle用户执行：

lsnrctl status

如果监听没起来，用lsnrctl start启动它。同时，确认你要监控的实例（对于CDB/PDB架构，就是具体的PDB）是打开状态。

接下来，创建用户并授权。这里有个权限规划的学问。给DBA角色最简单粗暴，但安全上存在风险。在实际生产环境，我倾向于授予一组最小化但足够的权限。下面这个脚本是我常用的，它赋予了Zabbix用户连接、查询任何表和数据字典的权限，这对于监控来说基本够用了：

-- 假设你已经连接到对应的PDB（如果是CDB架构） ALTER SESSION SET CONTAINER = PDB2; CREATE USER zabbix IDENTIFIED BY 你的强密码 DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; GRANT CONNECT, RESOURCE TO zabbix; GRANT SELECT ANY TABLE TO zabbix; GRANT SELECT ANY DICTIONARY TO zabbix; GRANT CREATE SESSION TO zabbix; GRANT UNLIMITED TABLESPACE TO zabbix;

创建好后，务必用这个新用户测试一下从Zabbix服务器能否连接过来。在Zabbix服务器上，使用刚安装的sqlplus：

sqlplus zabbix/你的密码@//数据库IP:1521/服务名

这个服务名很关键，不是实例名（SID），通常是你在tnsnames.ora里配置的服务名，或者PDB的可插拔数据库服务名。能连上，说明数据库这边的准备工作就OK了。

3. 核心配置：打通ODBC连接通道

环境准备好，我们就来到了最核心的一步：配置ODBC。这个过程就像给Zabbix和Oracle之间铺设一条专用的数据线，并且定义好通信协议。主要涉及两个配置文件：odbcinst.ini（告诉系统ODBC驱动在哪）和odbc.ini（定义具体要连接哪个数据库）。

3.1 配置环境变量与驱动文件

在配置ODBC之前，需要先设置环境变量，让系统知道Oracle客户端库的位置。编辑/etc/profile文件，在末尾添加：

export ORACLE_HOME=/usr/lib/oracle/19.22/client64 export PATH=$PATH:$ORACLE_HOME/bin export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH export TNS_ADMIN=$ORACLE_HOME/network/admin

注意，这里的ORACLE_HOME路径一定要和你实际安装的版本号（19.22）匹配。添加后执行source /etc/profile让配置生效。

接下来，找到ODBC驱动库文件，通常位于$ORACLE_HOME/lib/下，名字类似libsqora.so.19.1。确保这个文件有可执行权限：

chmod +x /usr/lib/oracle/19.22/client64/lib/libsqora.so.19.1

3.2 详解odbcinst.ini与odbc.ini

现在来配置/etc/odbcinst.ini。这个文件是ODBC驱动程序的注册表。添加一个名为[Oracle]的段落：

[Oracle] Description = Oracle ODBC driver for Oracle 19c Driver = /usr/lib/oracle/19.22/client64/lib/libsqora.so.19.1 Setup = FileUsage = CPTimeout = CPReuse =

最关键的就是Driver这一行，必须指向你刚才确认过的驱动库文件的绝对路径。这里的[Oracle]是一个驱动名称，后面会用到。

接着配置/etc/odbc.ini，这个文件定义了数据源（DSN）。一个DSN代表一个数据库连接。你可以定义多个DSN来监控不同的数据库。

[oracle_prod_93] # 这是数据源名称（DSN Name），自定义，后面Zabbix会用到 Driver = Oracle # 对应odbcinst.ini里定义的驱动名称 ServerName = 10.90.1.93:1521/orclcdb # 连接字符串：IP:端口/服务名 Port = 1521 UserID = zabbix Password = zabbix

这里有几个细节需要注意：

ServerName：这是连接的核心。格式是主机名或IP:端口/服务名。这个“服务名”就是之前用sqlplus测试连接时用的那个，通常是全局数据库名或PDB的服务名，而不是SID。
Driver：必须和odbcinst.ini中的括号内的名称（如[Oracle]）完全一致。
安全性：把密码明文写在/etc/odbc.ini里存在风险。在生产环境中，可以考虑使用/etc/odbc.ini定义DSN但不写密码，然后在Zabbix的监控项里单独配置密码（通过宏或加密存储），或者使用操作系统认证等更安全的方式。这里为了演示清晰，我们先采用明文方式。

配置完成后，用odbcinst -j命令可以查看ODBC的配置情况。如果看到unixODBC版本信息和配置文件路径，说明基础配置没问题。

3.3 使用isql进行连接测试

这是验证ODBC配置是否成功的“临门一脚”。使用isql这个命令行工具，它是unixODBC包自带的。

isql -v oracle_prod_93

这里的oracle_prod_93就是你odbc.ini里定义的DSN名称。如果一切配置正确，你会看到一个成功的连接提示符，类似于一个简单的SQL交互界面。这时你可以输入SELECT * FROM v$version;这样的简单SQL来测试查询。如果出现[IM002][unixODBC][Driver Manager]Data source name not found这类错误，说明DSN名称写错了或者配置文件路径不对。如果出现[01000][unixODBC][Driver Manager]Can‘t open lib之类的错误，说明驱动路径或驱动文件本身有问题。

这个测试环节至关重要，务必确保在命令行下能用isql连上并执行查询，再进入Zabbix的Web界面配置。很多Zabbix前端报错，根源都在这一步没通。

4. Zabbix Web界面配置与模板化监控

ODBC通道打通后，剩下的工作就是在Zabbix前台“搭积木”了。Zabbix提供了两种主要方式：手动创建自定义监控项和使用官方模板。我强烈建议从模板开始，效率高，覆盖全。

4.1 手动创建监控项：理解其原理

我们先看看手动创建的方式，这有助于理解底层原理。在Zabbix前端，进入【配置】->【主机】，找到你的Oracle数据库主机（如果没有，需要先创建一个主机，IP指向数据库服务器），然后进入【监控项】标签页，点击【创建监控项】。

关键配置如下：

名称：自定义，如“Oracle数据库版本”。
类型：选择“数据库监控”。
键值：自定义一个唯一的键，例如oracle.db.version。
数据库类型：选择“ODBC”。
ODBC数据源名称（DSN）：填写你在odbc.ini里定义的DSN，比如oracle_prod_93。
用户名/密码：如果odbc.ini里已经配置了，这里可以留空。否则需要填写。
SQL查询：输入你要执行的SQL语句，例如SELECT banner FROM v$version WHERE rownum=1;。

填写完成后，点击下方的【测试】按钮。如果配置正确，你会看到“成功”的提示，并显示SQL执行返回的结果。这个过程，其实就是Zabbix后端调用你配置好的ODBC驱动，通过DSN连接到数据库，执行你写的SQL，然后把结果抓取回来。手动创建适合监控一些非常定制化的、模板里没有的指标。

4.2 使用官方模板进行批量化监控

手动创建一两个监控项还行，但要监控数据库的健康状况，需要几十上百个指标（表空间、会话、锁、缓冲池命中率、等待事件等）。这时候，Zabbix官方提供的“Oracle by ODBC”模板就派上大用场了。

第一步，获取并导入模板。在Zabbix官网的模板分享页面，可以搜索并下载“Oracle by ODBC”模板（通常是一个.xml文件）。然后在Zabbix前端的【配置】->【模板】页面，点击【导入】，上传这个XML文件。

第二步，链接模板到主机。模板导入后，进入你的Oracle数据库主机的配置页面，在【模板】标签页，搜索“Oracle by ODBC”，添加它。这样，模板里预定义的所有监控项、触发器、图形就会自动关联到这台主机上。

第三步，也是最重要的一步：配置模板宏（Macro）。模板里的监控项不会写死连接信息，而是使用宏变量。你需要根据你的环境，修改这些宏的值。进入主机的【宏】标签页（或者模板的宏配置），通常需要设置以下几个关键宏：

{$ORACLE.DSN}：你的ODBC数据源名称，如oracle_prod_93。
{$ORACLE.USER}：监控数据库用户名，如zabbix。
{$ORACLE.PASSWORD}：对应用户的密码。
{$ORACLE.SERVICE}：数据库服务名（注意，有些模板可能用{$ORACLE.HOST}或{$ORACLE.CONNECT_STRING}来指代完整的连接信息，需要根据模板具体说明来调整）。

配置完宏之后，Zabbix服务器就会用这些宏值去填充每个监控项的连接参数，然后自动开始采集数据。你可以去【监测】->【最新数据】里，筛选该主机，看看是否已经开始收到Oracle数据库的各项指标了。

4.3 模板的定制与优化

直接使用官方模板可能不完全符合你的需求。比如，你可能想调整某些监控项的采集间隔，或者修改触发器的报警阈值。这时候，最好的做法不是直接修改原模板，而是“克隆”它。

在【配置】->【模板】页面，找到“Oracle by ODBC”模板，点击旁边的“全克隆”按钮。给克隆出来的新模板起个名字，比如“Oracle by ODBC_公司定制版”。然后，你就在这个克隆模板上随意修改了：可以禁用不需要的监控项，可以复制并修改SQL语句来监控特定的业务表，也可以调整触发器的严重程度。

我个人的习惯是，先让官方模板跑起来，收集一段时间的数据。然后根据历史数据曲线和业务的实际痛点，再来定制触发器。比如，表空间使用率的报警阈值，不同业务系统、不同数据增长率的数据库，肯定不能设成一样的。通过观察历史数据，设定一个合理的预警（如85%）和严重报警（如95%）阈值，这样告警才有意义，不会整天误报。

5. 生产环境部署的进阶技巧与排错指南

把监控跑起来只是第一步，要让它在生产环境里长期稳定、可靠地工作，还需要一些进阶的配置和排错经验。这部分是我多年实战中积累的干货。

5.1 高可用与负载考量

如果你的Zabbix Server是单点，那么它本身就会成为单点故障。对于核心数据库的监控，我建议采用Zabbix Proxy架构。将ODBC的配置和监控数据采集任务下放到离数据库更近的Proxy服务器上。这样即使Zabbix Server网络暂时中断，Proxy也能缓存数据，待恢复后一并上报。同时，这也能减轻Server端的压力，特别是在监控大量数据库实例时。

另一个考量是监控频率对数据库的影响。模板里有些监控项（比如查询v$session_wait）的SQL可能开销较大。你需要评估一下，将所有监控项的默认间隔（如30秒或1分钟）全部启用，是否会对生产数据库造成性能压力。我的做法是，对核心性能指标（如活动会话数、每秒事务数）保持较高频率（如30秒），而对一些容量类、变化较慢的指标（如表空间大小、对象数量）降低频率（如5分钟或15分钟）。在Zabbix监控项配置里可以很方便地调整这个“更新间隔”。

5.2 权限与安全加固

前面创建zabbix监控用户时，我们授予了SELECT ANY DICTIONARY等权限。这在很多安全审计严格的场景下可能通不过。我们可以进一步细化权限，只授予查询特定动态性能视图（V$视图）和静态数据字典视图（DBA_视图）的权限，而不是ANY。例如：

GRANT SELECT ON v_$session TO zabbix; GRANT SELECT ON v_$sysstat TO zabbix; GRANT SELECT ON dba_data_files TO zabbix; -- ... 根据模板中实际用到的视图，逐一授权

这需要你仔细分析模板中每个监控项用到的SQL，工作量较大，但安全性最高。一个折中的办法是，创建一个角色，将所需视图的查询权限授予这个角色，再把角色给zabbix用户。

关于密码存储，如前所述，明文存储在odbc.ini或Zabbix主机宏里不安全。Zabbix支持将宏的值设置为“秘密文本”，在前端显示为星号，并且Zabbix Server在启动时会将其加载到内存中，相对安全一些。更安全的方式是结合操作系统认证，但这需要更复杂的配置。

5.3 常见故障排查思路

即使按照步骤一步步来，也难免会遇到连接失败、数据采集不到的问题。我总结了一个排查清单，你可以按顺序检查：

基础连接测试：在Zabbix服务器上，用tnsping（如果配置了TNS）或sqlplus直接连接数据库，确保网络和数据库监听没问题。
ODBC驱动测试：使用isql -v your_dsn进行测试。这是隔离Zabbix，单独测试ODBC配置层。
检查Zabbix Server日志：查看Zabbix Server的日志文件（通常是/var/log/zabbix/zabbix_server.log），搜索“ODBC”或你的监控项键值，看是否有明确的错误信息。常见的错误如“Cannot connect to ODBC DSN: [unixODBC][Driver Manager]Data source name not found”说明DSN配置错误；“SQL error”则可能是SQL语句语法问题或权限不足。
检查ODBC驱动日志：Oracle的ODBC驱动可以开启详细日志。通过设置环境变量ODBCINI和ODBCINSTINI指向你的配置文件，并设置ODBC_TRACE和ODBC_TRACEFILE，可以将ODBC的调用细节输出到文件，这对于诊断复杂的连接问题非常有用。
检查监控项配置：确认Zabbix前端监控项里填写的DSN名称、用户名、密码与odbc.ini和数据库实际情况完全一致。特别注意大小写和特殊字符。
权限问题：在数据库端，尝试用zabbix监控用户登录，手动执行监控项里配置的SQL语句，看是否能成功返回数据。如果不能，就是权限问题。
版本兼容性：确认Oracle Instant Client版本与数据库版本大致兼容。过老或过新的客户端连接较老或较新的数据库时，可能会遇到一些不兼容的问题。

记住，排错的关键是分层隔离。先确保数据库本身可连，再确保ODBC层可连，最后再排查Zabbix层面的配置。按照这个顺序，大部分问题都能快速定位。

6. 从监控到洞察：构建价值仪表盘

数据采集上来不是终点，让数据产生价值才是。Zabbix采集了海量的Oracle指标，如果只是躺在“最新数据”里，或者只有触发告警时才被看到，那就太浪费了。我们需要把这些数据组织成直观的仪表盘（Dashboard），让DBA和运维人员一眼就能掌握数据库的健康全貌。

在Zabbix的【仪表盘】模块里，你可以创建专属的“Oracle数据库监控视图”。我通常会布置这几个核心组件：

资源概览部件：使用“时钟”或“简单图形”部件，集中展示几个最关键的指标当前值，比如“活动会话数”、“CPU使用率”、“缓冲区缓存命中率”、“每秒物理读”。让人一眼就知道数据库忙不忙。
性能趋势图：使用“图形”部件，将“每秒事务数”、“每秒逻辑读”、“用户调用次数”等性能指标放在一个时间轴上。通过观察曲线的波峰波谷，可以清晰地了解业务的繁忙时段和数据库的负载模式。
容量预测图：这是非常实用的一块。将各个表空间的使用率历史数据用图形展示出来，Zabbix自带趋势预测功能（虽然简单），可以大致判断照当前增长速度，表空间还能用多久。我习惯为每个重要表空间设置一个图形，并配上使用率的百分比进度条。
问题聚合视图：使用“问题”部件，筛选出与该Oracle主机相关的所有未解决的触发器告警。这样，当数据库出现异常时，所有相关的告警（如锁等待、会话池耗尽、归档日志空间不足）都会集中显示在这个仪表盘上，方便快速关联分析。

除了Zabbix原生的仪表盘，你还可以利用Zabbix的API将监控数据导出到更专业的可视化工具，比如Grafana。Grafana在图表美观度和交互性上更胜一筹。通过Zabbix插件或直接连接Zabbix数据库，可以在Grafana中构建更加炫酷和业务化的数据库监控大屏。

最终，我们的目标不仅仅是“监控”，而是“洞察”。通过持续观察这些仪表盘，你不仅能被动响应告警，更能主动发现潜在的性能瓶颈（比如某个SQL的等待事件突然增多），预测资源瓶颈（如表空间增长趋势），真正让监控系统成为保障数据库稳定运行的“眼睛”和“大脑”。这套基于ODBC和Zabbix的体系，一旦搭建完成并稳定运行，就会成为你运维工具箱里一件强大而可靠的武器。