企业官网建设流程全解析

OCI（Oracle Cloud Infrastructure）的托管数据库服务 DBaaS 在云平台自带的 Monitoring 中缺少数据库实例内部的细粒度指标，单靠 OCI Monitoring 难以满足日常巡检与容量告警需求。本指南以 community-templates 仓库中的template_zabbix_oci_dbaas模板为主线，完整解析其文件结构、agent 端部署方式、全部监控项（Items）、Tablespace 自动发现（LLD）与告警触发器，帮助读者在 Zabbix 环境中落地一套可运行、可扩展的 OCI DBaaS 监控方案。

为什么需要为 OCI DBaaS 引入 Zabbix 监控

模板 README 的 Overview 部分直接点明了设计动机：如果要对 DBaaS 进行监控，OCI Monitoring 自身的功能并不够用（甚至可能根本没有 DBaaS 对应的指标），因此有必要借助其他监控工具。

该模板给出的答案是「从数据库内部采集」：通过在承载 Oracle DB 的主机上部署 Zabbix agent，借助自定义 UserParameter 调用 shell 脚本与 SQL，把数据库实例内部的真实状态（表空间使用率、ASM 使用率、锁与阻塞会话、RMAN 备份问题等）反馈给 Zabbix Server。这种「agent + 脚本 + SQL」的模式可以拿到云平台监控控制台看不到的实例级数据。

按照模板说明，该模板已在 Zabbix 3 / 4 系列上验证可用；同时本仓库为它提供了 5.0（XML）、5.4（YAML）、6.0（YAML）三种格式的导出文件，兼容面覆盖了从老版本到新版本的导入场景。模板由作者 yu araki 维护，其开源项目名为zabbix-oci-dbaas。

模板文件结构与采集链路

README 中给出了下载包（即部署产物）的完整目录结构，这是理解整套监控机制的第一步：

zabbix-oci-dbaas ├── deploy_zabbix-oci-dbaas.sh # 在 Zabbix agent 主机上执行的 DBaaS 监控部署脚本 ├── README.md ├── template_oci_dbaas.xml # 需要导入 Zabbix 控制台的模板文件 └── zabbix-oci-dbaas/ # 放置到 /etc/zabbix/scripts/agentd/zabbix-oci-dbaas/ 下的文件 ├── zabbix_agentd.conf # UserParameter 参数定义 ├── zabbix-oci-dbaas.conf.org # OracleDB 监控的用户说明文件（模板） ├── zabbix-oci-dbaas.oraenv.org # Oracle 环境变量设置文件（模板） ├── zabbix-oci-dbaas.sh # 监控数据采集主脚本 └── sql/ # 存放各监控项对应的 SQL 语句 ├── xxx.sql └── …

各组成部分的职责如下：

从文件结构可以推断出完整的采集链路：

Zabbix Server │ 主动轮询（Zabbix agent / passive check） ▼ Zabbix Agent（UserParameter: zabbix-oci-dbaas[...]） ▼ zabbix-oci-dbaas.sh（解析 key 参数，加载 oraenv 环境） ▼ sqlplus 执行 sql/xxx.sql ▼ Oracle DBaaS 实例（V$ 系列视图 / 数据字典）

即：Zabbix Server 按监控项设定的更新周期（Update interval）轮询 agent，agent 根据 UserParameter 定义调用zabbix-oci-dbaas.sh，脚本在oraenv提供的 Oracle 环境下通过 sqlplus 执行对应 SQL，把查询结果作为监控项数值返回。

导入模板：三个版本任选

本仓库为同一模板维护了三套导出文件，导入时需按 Zabbix Server 版本选择对应文件：

从模板定义可以看出导入后的归属信息：

• 模板名：OCI_Dbaas
• 所属分组：DB: Oracle与Templates
• 应用（application）：Oracle
• 所有监控项统一打上标签Application=Oracle

导入后，将模板链接到承载 DBaaS 的主机，并在主机或模板级定义宏{$ORACLE_SID}（详见下文「宏配置要点」），即可开始采集。

agent 端部署：脚本、UserParameter 与环境变量

模板的监控数据完全由 agent 主机侧产生，因此 agent 端部署是关键一步。README 给出的部署方式是：在 agent 主机上执行deploy_zabbix-oci-dbaas.sh部署脚本，脚本会把zabbix-oci-dbaas/目录下的文件落到/etc/zabbix/scripts/agentd/zabbix-oci-dbaas/。

部署后需要确认或调整的内容包括：

1. UserParameter 定义（zabbix_agentd.conf）：模板所有监控项 key 都以zabbix-oci-dbaas[...]为前缀，agent 配置中必须声明对应的 UserParameter，将 key 映射为脚本调用，例如：

   UserParameter=zabbix-oci-dbaas[*],/etc/zabbix/scripts/agentd/zabbix-oci-dbaas/zabbix-oci-dbaas.sh "$1" "$2" "$3"

   （具体参数顺序以实际zabbix_agentd.conf内容为准；key 的后缀参数会原样传给脚本，由脚本解析。）

2. Oracle 环境变量（zabbix-oci-dbaas.oraenv.org）：采集脚本需要正确的ORACLE_SID、ORACLE_HOME等环境才能连接数据库执行 SQL。README 将其描述为「Environment variable settings」，即把.org模板按实际环境修改后作为脚本的环境来源。

3. 监控说明（zabbix-oci-dbaas.conf.org）：README 称之为「User description for OracleDB monitoring」，是给使用者看的配置说明，可结合部署环境按需调整。

4. SQL 文件（sql/目录）：每个监控项对应一个.sql文件，脚本按监控项参数选择并执行相应的 SQL。若数据库对象或权限环境有差异，可在此目录中核对 SQL 内容。

部署完成后，可在 agent 主机上用 Zabbix 自带的调试手段验证 UserParameter 是否生效，例如：

zabbix_agentd -t "zabbix-oci-dbaas[ORCL,db_active,1]"

若返回数值而非ZBX_NOTSUPPORTED，说明脚本链路已打通；也可在 Server 端用zabbix_get -s <agent_ip> -k "zabbix-oci-dbaas[ORCL,db_active,1]"做同样验证（将ORCL替换为实际的ORACLE_SID）。

监控项（Items）全解析

模板定义了 14 个固定监控项与 1 个 LLD 原型监控项。下表完整列出各监控项的名称、key、更新周期，以及从 5.4/6.0 YAML 中补充的单位、数值类型与历史/趋势保留策略：

按监控目标可以把这些监控项归纳为四类：

可用性与健康度：db_active（数据库是否 active 且 open）、db_uptime（数据库运行时长，秒）、db_version（版本号，字符型，不参与趋势计算）、db_size（数据库总体大小，每日采集一次即可）。

性能与并发：db_metric（Response Time Per Txn，事务响应时间，60 秒高频采集且保留 30 天以观察长期趋势，类型为 FLOAT）、db_block（阻塞会话数）、db_lock（锁数量）、db_connection（可用连接数）。其中db_block、db_lock更新周期仅 60s，历史保留 1 天、趋势保留 5 天，属于「高频、短保留」的实时诊断类指标。

容量与空间：db_fra（Flash Recovery Area 使用率 %）、db_asmdata（ASM Data Area 使用率 %）、db_asmreco（ASM Recovery Area 使用率 %）、db_redo（Redo Log 数量）、以及 LLD 生成的tb_size（每个表空间使用率 %）。这类指标均以百分比或计数形式呈现，是容量告警的主要数据来源。

对象与备份：db_invalid（失效对象数量）、db_rman（RMAN 问题计数）。失效对象往往由结构变更、升级或编译失败引起；RMAN 问题计数用于反映备份/恢复链路异常，按天检查一次。

一个值得注意的实现细节：Response Time Per Txn监控项的 key 为zabbix-oci-dbaas[{$ORACLE_SID},db_metric,'Response Time Per Txn']，即把指标名作为参数传入采集脚本。从 key 的形态可以推断，脚本内部会根据该参数在sql/目录中定位对应的 SQL 查询——这也是整套模板「一个 UserParameter、多种指标」设计的核心所在。

Tablespace 自动发现与图形原型

表空间数量多、名称随环境变化，模板没有把每个表空间写成固定监控项，而是使用**低层自动发现（LLD）**动态生成：

发现规则（Discovery rule）：

发现规则每 24 小时执行一次，返回当前实例的所有表空间列表，以宏{#ORACLE_TBS}作为发现宏供原型引用。发现规则的 key 由四段参数组成：{$ORACLE_SID}（实例标识）、tb_list（表空间列表动作）、1（预留参数）、ORACLE_TBS（发现宏名），最终生成{#ORACLE_TBS}宏。

监控项原型（Item prototype）：

注意名称中的$3会被 Zabbix 展开为 key 的第 3 个参数（即{#ORACLE_TBS}），因此实际生成的监控项名称是诸如「[Oracle] Tablespace USERS percentage used」这样的形式。每个发现的表空间每 10 分钟采集一次使用率。

图形原型（Graph prototype）：模板同时定义了[Oracle][{$ORACLE_SID}]Tablespace used: {#ORACLE_TBS}图形原型，类型为STACKED（堆叠图），Y 轴上下限固定，图元颜色C80000（深红），绘制在右侧 Y 轴。这样每个表空间被自动发现后，Zabbix 会自动为其生成对应的使用率图形，无需手工创建。

触发器与告警策略

README 的 Triggers 表格只列出了 4 条与表空间相关的触发器；但核对 5.0 XML 与 5.4/6.0 YAML 后可以发现，模板文件中实际内置了更多告警规则，覆盖可用性、容量、并发与备份多类场景。以下为模板文件中的完整触发器清单：

（README 中列出的 4 条表空间触发器为 5.0 语法写法：{OCI_Dbaas:zabbix-oci-dbaas[{$ORACLE_SID},tb_size,{#ORACLE_TBS}].last()}>95，其中两条带(LLD)后缀的是触发器原型在自动发现时生成的实体，与原型定义实质相同。）

这些触发器在设计上有几个值得借鉴的点：

• 双阈值分级：表空间使用率采用 95%（HIGH）与 90%～95%（WARNING）两级阈值，FRA 采用 90%（HIGH）与 80%（WARNING）两级，既避免一上来就告警，又能在逼近危险水位时升级。
• 趋势型告警：阻塞会话、锁、失效对象三个指标使用change(...) > 0判断「数量正在增长」而非绝对值，用于捕获并发问题的恶化趋势。
• 依赖关系（dependencies）：FRA 的 WARNING 触发器依赖 HIGH 触发器，数据库重启（INFO）触发器依赖「inactive or closed」（HIGH）触发器，避免同一根因触发多条告警造成告警风暴。
• 默认禁用：重启检测触发器默认DISABLED（status: DISABLED），需要时再手工启用。

宏配置要点

README 的「Macros used」章节注明模板没有定义宏链接，也没有模板链接。但所有监控项 key 中都引用了{$ORACLE_SID}宏，因此实际使用中必须在主机或模板层为{$ORACLE_SID}赋值（即被监控数据库的实例名，例如ORCL）。这是让整套模板从「定义」变成「可运行」的唯一关键配置项。

其余采集相关配置（ORACLE_HOME、连接凭据等）不在模板宏中体现，而是通过 agent 端的zabbix-oci-dbaas.oraenv.org与脚本环境完成，符合「模板只管指标、环境交给主机侧」的社区模板惯例。

三个版本（5.0 / 5.4 / 6.0）的差异

三套文件在监控项、发现规则、触发器逻辑上完全一致，差异主要体现在导出格式与表达式语法：

• 5.0：XML 格式（template_zabbix_oci_dbaas.xml），触发器表达式使用旧式写法，如{last()}>90、{change(0)}>0、{OCI_Dbaas:zabbix-oci-dbaas[...].last()}>95。
• 5.4 / 6.0：YAML 格式，触发器表达式改用新式函数语法，如last(/OCI_Dbaas/zabbix-oci-dbaas[{$ORACLE_SID},db_fra,1])>90，并显式声明各监控项的history、trends、units、value_type与tags。

因此从 5.0 升到 5.4/6.0 时，除了换用对应格式的导入文件外，告警表达式会被 Zabbix 自动迁移，无需手工改写。若目标 Server 是 3.x/4.x 老版本，则应参考 README 的验证说明，并优先以 XML 版本为基础核对兼容性。

运维建议与常见问题

基于模板结构与监控项特性，给出以下落地与排障建议：

1. 部署顺序：先在 agent 主机执行deploy_zabbix-oci-dbaas.sh完成脚本与 SQL 落盘，再在 Zabbix 控制台导入模板并关联主机，否则监控项会因找不到 UserParameter 而报ZBX_NOTSUPPORTED。
2. 环境变量先行：oraenv相关的ORACLE_SID/ORACLE_HOME必须与数据库实例一致；db_active返回 0 或所有监控项无数据时，优先检查 agent 主机能否用 sqlplus 正常连接。
3. 采集频率与开销：模板把高频项（60s 的db_block、db_lock、db_metric）与低频项（86400s 的db_size、db_version、db_rman）分开设置，部署时保持默认周期即可；若实例数量多，可适当拉长低频项周期。
4. 告警阈值按需调整：表空间 95%/90% 阈值对绝大多数业务合理，但对写入密集的实例，可结合db_fra、db_asmdata的 90% 阈值联动观察，避免单点容量告警掩盖整体空间压力。
5. LLD 生命周期：Tablespace 发现规则生命周期为 1 天，删除的表空间会在一天后自动从监控中移除，无需手工清理。
6. 排障入口：验证单条监控项可用zabbix_get/zabbix_agentd -t直接取 key 值；核对模板内容可对照 6.0 YAML 中每个 item 的key、delay、units字段，与 Server 端实际配置比对。

综上所述，template_zabbix_oci_dbaas是一套典型的「agent 侧脚本 + LLD 自动发现」型 Zabbix 社区模板：用一套 UserParameter 覆盖实例健康、性能、容量与备份四大类指标，用自动发现解决表空间动态变化问题，用分级阈值与依赖关系控制告警质量。对使用 OCI DBaaS 又希望获得实例级可观测性的团队而言，它是一条低门槛、可立即上手的落地方案。