1. 为什么选择ODBC这条路来监控Oracle1.1 监控Oracle的几种常见路子对比但凡做过数据库监控的人都知道Oracle这套东西的监控方案其实挺多的但每条路都有自己的坑。我最早用的是Oracle自带的Enterprise Manager功能确实全但部署重、资源占用高而且跟Zabbix这种统一监控平台对接起来很别扭。后来试过写自定义脚本用sqlplus定时跑SQL然后把结果推给Zabbix脚本维护成本高密码管理也麻烦一旦数据库版本升级或者网络抖动脚本就各种报错。再后来就是ODBC这条路。Zabbix从很早的版本就内置了数据库监控模板通过ODBC驱动去连数据库把查询结果直接映射成Zabbix的item。Zabbix 5.4这个版本对ODBC的支持已经比较成熟了配置起来比写脚本省心得多。核心思路就是在Zabbix Server或者Proxy上装好Oracle的ODBC驱动配好数据源然后在Zabbix里建一个ODBC类型的监控项写一条SQLZabbix定时去查查回来的值直接入库。这条路的好处很明显不用在数据库服务器上装agent不用写额外的脚本SQL改起来也方便。坏处也有ODBC驱动本身有点挑环境Oracle的Instant Client版本、unixODBC的配置、字符集这些细节没弄对就会一直报错。1.2 这套方案适合什么样的场景我先把话说在前面这套方案不是万能的。它最适合的场景是你已经有一套Zabbix在跑想把手里的Oracle数据库纳进来统一监控又不想在数据库服务器上装一堆东西。查询的内容主要是那些能通过一条SQL拿到单个数值的指标比如会话数、表空间使用率、等待事件计数、归档日志切换频率这些。如果你要监控的是那种需要复杂逻辑判断、多步关联查询才能得出的指标ODBC这条路就会比较吃力因为Zabbix的ODBC监控项本质上就是“执行一条SQL取一个值”。复杂逻辑要么写成一条足够复杂的SQL要么就得考虑别的方案。另外要注意ODBC监控对数据库本身是有一定压力的。每次取数都是一次真实的数据库连接和查询如果监控项很多、采集间隔很短累积起来对数据库的连接数和CPU都是有影响的。所以采集频率和SQL的写法都要讲究。1.3 整体架构长什么样整个链路是这样的Zabbix Server或者Proxy上装了unixODBC和Oracle Instant Client配好了一个ODBC数据源指向目标Oracle库。Zabbix通过这个数据源执行SQL拿到结果后存进自己的数据库再由前端展示和触发告警。这里有个关键点很多人会忽略Zabbix执行ODBC查询是以Zabbix运行用户的身份去执行的通常是zabbix用户。所以ODBC的配置文件、驱动路径、环境变量都必须对zabbix用户可见可用。我见过太多人用root配好了测试通过结果Zabbix里一直报“Cannot connect to ODBC DSN”就是因为zabbix用户读不到配置。2. 环境准备与驱动安装的实操细节2.1 Oracle Instant Client的选型与安装Oracle官方提供的即时客户端Instant Client是走ODBC这条路必须装的东西。版本选择上我建议跟你要监控的Oracle数据库大版本对齐比如监控11g的库就用11.2的Instant Client监控19c的库就用19.x的。跨大版本虽然很多时候也能用但遇到字符集或者协议兼容问题会很头疼。安装Instant Client有两种方式一种是Basic包加ODBC包另一种是Basic Light包加ODBC包。我一般用Basic加ODBC因为Basic包里带的库文件更全省得后面缺东西。下载下来是两个zip包解压到同一个目录比如/usr/lib/oracle/19.6/client64。解压完之后要做几件事。第一是建软链接把版本号带在文件名里的库文件链接成不带版本号的因为ODBC驱动配置里写的是不带版本号的名字。第二是配环境变量LD_LIBRARY_PATH要指向Instant Client的目录这个变量对zabbix用户也必须生效。# 解压后的目录结构大概是这样的 /usr/lib/oracle/19.6/client64/ ├── lib/ │ ├── libclntsh.so.19.1 │ ├── libsqora.so.19.1 │ └── ... ├── bin/ └── ... # 建软链接 cd /usr/lib/oracle/19.6/client64/lib ln -s libclntsh.so.19.1 libclntsh.so ln -s libsqora.so.19.1 libsqora.so环境变量这块我建议直接写到/etc/ld.so.conf.d/下面然后跑ldconfig这样比依赖LD_LIBRARY_PATH更稳因为Zabbix作为服务启动时环境变量不一定能继承到。echo /usr/lib/oracle/19.6/client64/lib /etc/ld.so.conf.d/oracle-instantclient.conf ldconfig2.2 unixODBC的安装与驱动注册unixODBC是ODBC在Linux上的实现Zabbix的ODBC功能就是通过它来调用的。安装很简单用系统包管理器就行。CentOS系是yum install unixODBC unixODBC-develDebian系是apt install unixODBC unixODBC-dev。装完之后有两个配置文件要关注/etc/odbcinst.ini是注册驱动的/etc/odbc.ini是定义数据源的。驱动注册这块要把Oracle的ODBC驱动路径写进去。# /etc/odbcinst.ini [Oracle19c] Description Oracle ODBC driver for Oracle 19c Driver /usr/lib/oracle/19.6/client64/lib/libsqora.so Setup FileUsage CPTimeout CPReuse 这里有个细节Driver这一行写的是libsqora.so也就是我们前面建了软链接的那个。如果你没建软链接直接写libsqora.so.19.1也行但软链接的方式更通用以后升级版本不用改配置。2.3 数据源配置与连接测试数据源配置在/etc/odbc.ini里每个数据源一个section。关键参数是Driver要跟odbcinst.ini里的section名对上ServerName写数据库的连接串。# /etc/odbc.ini [ORCL_MONITOR] Description Oracle Monitor DSN Driver Oracle19c ServerName (DESCRIPTION(ADDRESS(PROTOCOLTCP)(HOST10.0.0.100)(PORT1521))(CONNECT_DATA(SERVICE_NAMEORCLPDB))) UserID monitor_user Password your_password配好之后用isql命令测试。isql -v ORCL_MONITOR能进去并且能执行select 1 from dual就说明链路通了。这一步非常关键一定要在配Zabbix之前先测通否则后面出了问题你分不清是ODBC的问题还是Zabbix的问题。注意密码明文写在odbc.ini里是有安全风险的。生产环境建议把文件权限设成600属主设成zabbix或者用Oracle的external password store。我见过有人图省事把密码写在全局可读的文件里这等于把数据库账号暴露了。3. Zabbix侧的配置与监控项落地3.1 在Zabbix里创建ODBC类型的监控项Zabbix 5.4里创建ODBC监控项的入口在“配置”-“主机”-“监控项”-“创建监控项”。类型选“数据库监控”然后关键信息填在几个地方。“键值”这一栏的格式是db.odbc.select[唯一标识,DSN名称]。比如db.odbc.select[session_count,ORCL_MONITOR]。这个唯一标识是给这个查询起个名字Zabbix内部用来区分不同的查询随便起但别重复。“用户名”和“密码”这两栏如果你在odbc.ini里已经写了UserID和Password这里可以留空。但我的习惯是odbc.ini里不写密码在Zabbix的监控项里用宏来传这样密码管理更集中改密码不用去动ODBC配置文件。“SQL查询”这一栏就是写你要执行的SQL。注意这里只能写一条返回单个值的SQLZabbix会把第一行第一列的值取走。如果你的SQL返回多行多列Zabbix只会取第一个值其他的忽略。“更新间隔”根据指标的重要程度来定。会话数这种变化快的可以30秒一次表空间使用率这种变化慢的5分钟一次就够了。别所有指标都设成30秒那样对数据库压力太大。3.2 几个实用的监控SQL示例会话数监控是最基础的查当前活跃会话数SELECT COUNT(*) FROM v$session WHERE status ACTIVE AND type USER表空间使用率这个稍微复杂一点因为要算百分比SELECT ROUND(used_percent, 2) FROM dba_tablespace_usage_metrics WHERE tablespace_name USERS归档日志切换频率查最近一小时的切换次数SELECT COUNT(*) FROM v$archived_log WHERE completion_time SYSDATE - 1/24等待事件里非空闲等待的总数SELECT COUNT(*) FROM v$session WHERE wait_class Idle AND status ACTIVE这些SQL有个共同特点都是返回单个数值。这是ODBC监控项的基本要求。如果你需要返回多个值要么拆成多个监控项要么用Zabbix的依赖项功能从一个主查询里派生。3.3 用宏来管理连接信息和阈值Zabbix的宏系统在这套方案里能帮大忙。我一般会定义几个主机级别的宏{$ORACLE_DSN}存DSN名称{$ORACLE_USER}和{$ORACLE_PASSWORD}存账号密码{$ORACLE_SERVICE}存服务名。这样在监控项和触发器里引用宏换数据库的时候只改宏就行不用一个个去改监控项。密码用宏来存有个好处Zabbix前端里宏的值可以设成“秘密文本”类型界面上显示成星号不会明文暴露。虽然底层存储还是明文但至少不会在界面上被人瞄到。触发器的阈值也用宏比如{$SESSION_WARN}设成200{$SESSION_CRIT}设成500。这样不同数据库可以根据自己的实际情况调阈值不用改触发器表达式。4. 踩过的坑与排查经验实录4.1 连接类问题的排查思路“Cannot connect to ODBC DSN”这个报错我见过太多次了原因五花八门。排查的时候按这个顺序来先用isql以root身份测通了再用sudo -u zabbix isql测。如果root能通zabbix不能通那基本就是权限或者环境变量的问题。权限问题常见的是/etc/odbc.ini和/etc/odbcinst.ini的读权限还有Instant Client目录的执行权限。zabbix用户需要对整个路径有执行权限才能加载到库文件。环境变量问题就是LD_LIBRARY_PATH或者ldconfig没配好zabbix用户加载不到libclntsh.so。还有一个隐蔽的坑是SELinux。如果系统开了SELinuxZabbix进程可能被限制访问ODBC配置文件。临时用setenforce 0测一下如果关了就好了那就得去配SELinux策略或者干脆把SELinux设成permissive。4.2 字符集与中文乱码的处理Oracle的字符集和客户端字符集不一致的时候查出来的中文会变成问号或者乱码。ODBC这块要在数据源配置里加一个参数指定客户端字符集。在odbc.ini的DSN section里加Charset UTF-8或者跟数据库一致的字符集。如果数据库是ZHS16GBK而客户端设成UTF-8虽然不会乱码但可能会有转换开销。最稳的做法是让客户端字符集跟数据库字符集一致。查数据库字符集用SELECT value FROM nls_database_parameters WHERE parameter NLS_CHARACTERSET。4.3 性能影响与采集频率的平衡ODBC监控对数据库的压力主要来自两方面连接建立的开销和查询本身的开销。每次采集都是一次完整的连接、认证、查询、断开的过程。如果监控项有几十个每个都30秒采一次那数据库上会看到持续的连接风暴。我的做法是把监控项按重要程度分级。核心指标比如会话数、活跃事务数30秒到1分钟采一次。次要指标比如表空间使用率、归档日志量5到10分钟采一次。另外SQL本身要优化尽量走V$视图和DBA视图这些视图的数据基本都在内存里查询开销很小。避免在监控SQL里做全表扫描或者复杂的关联查询。还有一个技巧是用Zabbix的“主监控项”加“依赖项”。比如你有一个查询返回了多个值拼成的字符串可以用一个ODBC监控项取回来然后用依赖项配合预处理来拆分。这样只需要一次数据库查询就能得到多个指标减少连接次数。4.4 常见报错速查表报错信息可能原因解决方法Cannot connect to ODBC DSNDSN名称写错、odbc.ini路径不对、权限不足检查DSN名称拼写确认odbc.ini位置用zabbix用户测试isqlData source name not foundodbcinst.ini里驱动没注册或驱动路径错误检查odbcinst.ini的Driver路径确认libsqora.so存在ORA-12154: TNS could not resolveServerName连接串写错或网络不通用tnsping测试连接串检查防火墙和监听ORA-28000: account is locked监控账号被锁解锁账号检查是否密码过期策略导致查询返回空值导致监控项变unsupportedSQL没查到数据用NVL或COALESCE给默认值确保SQL总能返回一行中文显示为问号字符集不匹配在odbc.ini里加Charset参数与数据库字符集对齐5. 监控模板的组织与告警联动5.1 模板结构的设计建议我习惯把Oracle监控做成一个模板模板里包含所有监控项、触发器和图形。模板上挂宏主机上链接模板后只需要覆盖宏的值就行。模板的命名要有规律比如“Template DB Oracle by ODBC”这样在模板列表里一眼就能找到。监控项的命名也要规范用“服务名.指标名”的格式比如“ORCLPDB.Session.Active”。这样在最新数据页面和图形里看起来整齐也方便做聚合。触发器这块我一般分两级Warning和Critical。Warning的阈值设得保守一点Critical设得激进一点。比如会话数Warning设200Critical设500。触发器表达式里引用宏这样不同数据库可以调不同的阈值。5.2 告警信息的有效组织告警信息里要包含足够的信息让人能快速定位问题。我一般会在告警描述里带上数据库服务名、当前值、阈值。比如“Oracle数据库ORCLPDB活跃会话数当前为523超过严重阈值500”。这样收到告警的人不用登录Zabbix就能知道大概情况。告警的恢复通知也要配不然只报不恢复运维人员不知道问题什么时候解决的。Zabbix的触发器默认就有恢复事件只要在动作里勾上“恢复消息”就行。5.3 图形与仪表盘的搭配ODBC监控项采集到的数据可以自动生成图形。我一般会给每个数据库建一个仪表盘把关键指标的图形放上去会话数趋势、表空间使用率、归档日志切换频率、等待事件分布。这样值班的人打开仪表盘就能对数据库的健康状况一目了然。图形的时间范围默认是1小时但数据库的很多问题是要看趋势的所以我会额外配一个24小时的图形。Zabbix 5.4支持在仪表盘上放多个图形布局用网格模式看起来比较整齐。6. 几个容易被忽略的细节6.1 监控账号的权限最小化用来做监控的Oracle账号权限给到能查V$视图和DBA视图就行千万别用system或者sys。我一般会建一个专门的监控账号授予SELECT_CATALOG_ROLE和SELECT ANY DICTIONARY权限这两个权限足够查绝大多数监控需要的视图了。CREATE USER monitor_user IDENTIFIED BY strong_password; GRANT CREATE SESSION TO monitor_user; GRANT SELECT_CATALOG_ROLE TO monitor_user; GRANT SELECT ANY DICTIONARY TO monitor_user;密码策略也要注意如果数据库设了密码过期策略监控账号的密码到期后连接就会失败监控项全部变unsupported。要么给监控账号设一个不过期的profile要么把密码过期纳入监控本身。6.2 Zabbix Proxy场景下的注意事项如果Zabbix是通过Proxy来采集的那ODBC的配置要在Proxy上做不是Server上。Proxy上的ODBC配置和Server上完全一样但要注意Proxy和Server的Zabbix版本要一致ODBC驱动版本也要一致否则可能出现Server能解析的监控项Proxy解析不了的情况。Proxy采集到的数据会先缓存在本地网络恢复后再传给Server。这个机制对ODBC监控是透明的不用额外配置。但要注意Proxy本地的数据库空间如果网络断太久缓存数据太多可能把Proxy的磁盘撑满。6.3 版本升级时的兼容性检查Zabbix从5.4升级到6.0或者更高版本时ODBC相关的配置基本是兼容的但有几个点要检查。一是ODBC监控项的键值格式有没有变化二是预处理功能有没有增强导致旧配置行为改变三是Oracle Instant Client的版本要不要跟着升。我的经验是升级前先在测试环境把ODBC监控项跑一遍确认所有监控项都能正常采集。升级后重点看那些用了预处理和依赖项的监控项这些是最容易出兼容问题的地方。6.4 监控数据的历史留存策略ODBC采集的数据跟其他Zabbix数据一样存在Zabbix自己的数据库里。如果监控项很多、采集频率很高历史数据会增长得很快。我一般会给ODBC监控项配一个合理的历史留存期比如趋势数据保留90天历史数据保留7天。这样既能看长期趋势又不会把数据库撑爆。Zabbix 5.4里可以在监控项级别配“历史数据保留时长”和“趋势数据保留时长”。对于变化缓慢的指标比如表空间使用率历史数据保留1天就够了趋势数据保留一年。对于变化快的指标比如会话数历史数据保留7天趋势数据保留90天。这套ODBC监控Oracle的方案我从Zabbix 4.x时代就开始用一路用到5.4中间踩过的坑基本都在这了。核心就一句话ODBC配置要先用isql测通再用zabbix用户测一遍最后才去Zabbix里配监控项。顺序反了排查起来就是一团乱麻。另外监控SQL尽量简单能走V$视图就别走DBA视图能一次查询拿到的就别拆成多次。数据库监控这件事对生产库的侵入性越小越好。
