企业官网建设流程全解析

本文以 community-templates 仓库中 Databases/Oracle/template_3.0_for_pyora 目录下的模板文档与导入文件为对象，完整解析名为Pyora active send的 Zabbix 模板：它如何基于 PyOra 的主动发送（active send）机制，通过 trapper 与低级别发现（LLD）实现对 Oracle 实例、表空间、临时表空间、ASM 卷和数据库用户的全面监控。读完本文，你将掌握该模板的宏配置、发现规则、采集项与触发器体系，并能在 Zabbix 5.0/5.4/6.0 环境中正确导入、配置与调优这套 Oracle 监控方案。

模板背景：为什么需要一个"修复版" PyOra 模板

PyOra（PyOra for Zabbix）是社区中广泛使用的 Oracle 监控工具：它用 Python 脚本查询 Oracle 动态性能视图，再把结果通过zabbix_sender主动推送给 Zabbix Server 的 trapper 监控项（Item）。这种"脚本采集 + 主动推送"的架构，避免了在数据库主机上长期占用 Zabbix Agent 轮询连接，也天然适配"只读账号 + 单向出站"的安全环境。

然而，原版模板是为旧版本 Zabbix 设计的，直接导入新版本会出现兼容性问题。本模板的作者在 Overview 中明确说明：

This is the fixed template for Zabbix PyOra to work on 3.0. I remove the unsupported tags and downgraded version. Note you will most likely have to update the triggers manually.

即：该模板去掉了新版 Zabbix 不支持的标签（tags），并降级了导出版本，使其能稳定工作在 Zabbix 3.0 上；同时提醒使用者——触发器（triggers）大概率需要根据实际环境手动更新。

值得注意的是，这个"面向 3.0 的修复版"模板，在仓库中同时以三种导出格式存放：

三份文件的导出时间均为2021-11-21T21:26:5xZ，且 YAML 中模板 UUID 一致（7eae89aae9d747498d89b12d7f25df33），说明它们是同一模板针对不同 Zabbix 版本生成的导出物，可按需选用。仓库根 README.md 的模板索引中也收录了该模板（Pyora active send）。

模板总体结构：一个纯 trapper 的"主动发送"模板

导入后，模板名为Pyora active send，归属于Pyora与Templates两个模板组，共定义了 5 个应用（Application）：Oracle、ASM Volumes、Tablespaces、Temp Tablespaces、Database Users。

从 5.4 YAML 与 5.0 XML 的实现看，模板呈现三个鲜明特征：

1. 几乎全部采用 Zabbix trapper（TRAP）类型：普通指标项（如commits、uptime、version）与 LLD 原型项（如tablespace[{#TABLESPACE}]）均为 trapper，delay为0，完全依赖 PyOra 脚本主动推数，Zabbix 侧不做轮询。
2. 少量辅助项用 Zabbix agent 类型：仅Zabbix items list（pyora-items-list[...]）为 agent 项，更新周期 3600 秒，用于校验 PyOra 脚本是否成功在 Zabbix 中创建了完整条目清单。
3. 无模板链接（Template links）：README 明确标注 "There are no template links in this template."，该模板不依赖任何其他模板。

数据流

Oracle 数据库 │ （只读账号查询 v$ 视图） ▼ PyOra Python 脚本（在数据库主机或独立采集机上运行） │ zabbix_sender 主动推送（trapper items，delay=0） ▼ Zabbix Server ── trapper items ── 预处理器 ── 历史/趋势 ── 触发器告警 ▲ └── Zabbix Agent 每 3600s 轮询 pyora-items-list 做完整性自检

宏定义（Macros）：接入前必须配置的变量

模板在 README 宏表 中列出了 6 个宏，与 XML 宏定义 一一对应：

此外，模板中的 item 键还引用了一个未在宏表中列出但实际被使用的宏{$ADDRESS}（出现在所有pyora-discovery[...]与pyora-items-list[...]键中，指 Oracle 实例地址）以及{$ARCHIVE}（用于check_archive[{$ARCHIVE}]监控项）。在 5.4/6.0 YAML 的宏区 中同样只能看到{$ASMHIGH}、{$DATABASE}、{$HIGH}、{$ZABBIXPASSWORD}、{$ZABBIXURL}、{$ZABBIXUSER}六个宏定义，因此{$ADDRESS}、{$ARCHIVE}需要在主机级或模板级手动补充。部署时建议在主机上统一设置，否则带{$ADDRESS}的发现规则与自检项会因宏未解析而失效。

低级别发现（LLD）规则：自动盘点 Oracle 对象

模板通过 4 条发现规则实现"自动发现、自动建项"（详见 README Discovery rules）：

这些规则由 PyOra 脚本的 discovery 输出驱动：脚本按show_*参数分别返回临时表空间、表空间、ASM 卷、数据库用户清单，Zabbix 据此生成对应的 LLD 原型项。需要特别注意：5.4 YAML 与 6.0 YAML 中，Discovery Oracle tablespaces与Discovery Oracle users两条规则的状态为DISABLED（5.0 XML 中同样标注status>DISABLED），意味着导入后默认不会执行发现，需要按需启用。

各规则生成的原型项如下：

• ASM 卷发现（应用ASM Volumes）：
  • asm_volume_free[{#ASMVOLUME}]（ASM Volume Free，单位 B）
  • asm_volume_size[{#ASMVOLUME}]（ASM Volume Size，单位 B）
  • asm_volume_use[{#ASMVOLUME}]（ASM Volume Use，单位 %）
• 表空间发现（应用Tablespaces）：
  • tablespace[{#TABLESPACE}]（Tablespace percentual use，单位 %，FLOAT）
  • tablespace_abs[{#TABLESPACE}]（Tablespace free，单位 bytes）
• 临时表空间发现（应用Temp Tablespaces）：
  • tablespace_temp[{#TABLESPACE_TEMP}]（Temp Tablespace Use，单位 %，FLOAT）
• 用户发现（应用Database Users）：
  • user_status[{#DBUSER}]（{#DBUSER} user status，TEXT 类型，原型本身状态为 DISABLED）

所有 LLD 原型项同样都是 trapper（TRAP），delay=0，等待 PyOra 按{#宏}展开后的具体键推送数据。

采集指标（Items）：47 个 trapper 指标 + 7 个 LLD 原型

模板的采集项几乎覆盖了 Oracle 性能监控的核心维度（完整清单见 README Items collected 与 XML items 区）。除Zabbix items list外，全部为Zabbix trapper、Update: 0。按监控维度可归纳为以下几组：

实例与运行状态

性能与等待事件

事务、日志与锁

容量与增长

系统指标（sysmetrics）

这三个指标直接对应 Oracle AWR 中的经典比率指标，PyOra 通过query_sysmetrics[指标名]参数化的键按名称取数，FLOAT 类型存储。

自检与完整性

其中Zabbix items list会调用 Zabbix API（URL/用户名/密码均来自宏），把当前主机上应存在的条目清单写入该 item；若输出中不包含关键字OK，将触发Can't create items list告警（详见下节），是这套模板"安装是否正确"的体检指标。

预处理器（Preprocessing）：让原始计数变成可读指标

从 YAML items 定义 可以看到模板为不同指标配置了三种预处理器：

这三类预处理器正是 PyOra"原始值上报、Zabbix 侧加工"思路的体现：脚本只负责把 Oracle 视图里的计数值、布尔标志和 MB 尺寸推过来，速率、归一化和单位换算全部交给 Zabbix 预处理完成，从而保持采集端脚本简单、可移植。

触发器体系：从灾难告警到容量预警

模板内置的触发器在 README Triggers 中公开了 4 条，而 XML 与 YAML 实际内置了更多，按严重级别汇总如下：

新旧版本表达式语法的差异（README 提醒"需手动更新触发器"的由来）

对比三个版本的导出文件，能直观看到 Zabbix 触发器语法的演进：

• 5.0 XML 使用 Zabbix 3.x 时代的旧式简写：如{Pyora active send:asm_volume_size[{#ASMVOLUME}].last()}、{regexp(ORA)}=1、{nodata(800)}=1、{last()}>80。
• 5.4/6.0 YAML 已改写为新式函数语法：last(/Pyora active send/... )、find(/Pyora active send/check_active,,"regexp","ORA")=1、nodata(/Pyora active send/check_active,800s)=1、length(last(...))。

这就是作者在 Overview 中提示 "you will most likely have to update the triggers manually" 的原因：模板从旧版迁移而来，跨版本导入后，旧式表达式在新版 Zabbix 中可能无法直接解析，需要按下表对照改写。README 的 Triggers 表中表达式仍保留硬编码阈值（> 85、> 80），而 YAML/XML 中的触发器原型已改用宏（>{$ASMHIGH}、>{$HIGH}），配置时建议统一以宏为准，便于批量调整阈值。

部署步骤：导入、配置与验证

1. 选择版本并导入

按目标 Zabbix 版本选择导入文件（通过 Zabbix 前端Configuration → Templates → Import）：

2. 配置宏

在主机（或模板）上设置以下宏：

• {$DATABASE}：Oracle 实例名（如ORCL）
• {$ADDRESS}：Oracle 实例地址（发现规则与 items-list 键使用）
• {$ZABBIXURL}/{$ZABBIXUSER}/{$ZABBIXPASSWORD}：Zabbix API 三要素，供pyora-items-list自检使用
• 阈值宏{$HIGH}（默认 80）、{$ASMHIGH}（默认 85）可按业务调整
• 如启用归档检查，还需{$ARCHIVE}

3. 挂载主机并启用需要的规则

把模板链接到 Oracle 主机后，按需启用默认 DISABLED 的发现规则（show_tablespaces、show_users）与指标项（enqueue、fra_use、freebufwaits、lastapplarclog、check_archive、user_status原型等）。

4. 验证数据流

• 确认 PyOra 脚本能连接 Oracle 并以只读账号取数；
• 确认脚本通过zabbix_sender推送的键名与模板 item 键一一对应；
• 观察Zabbix items list项的值是否包含OK，若触发Can't create items list，则说明 API 宏配置或脚本侧条目生成存在问题；
• 检查failedchecks是否为 0，非 0 时触发Zabbix sender failed checks count告警，提示存在推送失败的键。

注意事项与适用前提

• 版本适配：本模板名为 "3.0"，实际为适配 Zabbix 3.0 的修复版，仓库以 5.0/5.4/6.0 导出格式提供。导入前请确认目标 Zabbix 版本，5.0 版本使用 XML，5.4/6.0 使用 YAML；旧式触发器表达式跨版本导入后可能需要手动改写（参见上文新旧语法对照）。
• 默认禁用项：多条发现规则、指标与原型（show_tablespaces、show_users、fra_use、enqueue、freebufwaits、lastapplarclog、check_archive、user_status）默认 DISABLED，需按监控需求启用；query_lock的触发器在 XML 中状态亦为 DISABLED。
• 宏完整性：{$ADDRESS}、{$ARCHIVE}未出现在模板宏表中，必须自行补充，否则相关键无法解析。
• 采集前提：所有 trapper 指标依赖 PyOra 脚本主动推送，若脚本未运行或数据库账号权限不足，Zabbix 侧只会呈现"无数据"，不会主动报错，需结合nodata类触发器与failedchecks综合判断。
• 阈值合理性：触发器阈值（表空间 80%、ASM 85%、FRA 90%、会话 250、无数据 800s 等）均为模板默认值，生产环境请结合实例规格与容量规划调整，并优先通过宏{$HIGH}、{$ASMHIGH}管理，避免直接改动硬编码表达式。

小结

Pyora active send模板完整呈现了一套"PyOra 主动推送 + Zabbix trapper 接收 + LLD 自动发现 + 预处理加工"的 Oracle 监控范式：47 个常规 trapper 指标覆盖实例状态、等待事件、事务日志、锁与容量维度，7 个 LLD 原型实现表空间、临时表空间、ASM 卷与用户的自动盘点，而pyora-items-list与failedchecks则为整套链路提供了自我校验能力。对于仍在维护 Zabbix 3.0 时代 PyOra 方案、或希望在新版 Zabbix 上复用该采集架构的团队，仓库中 README 与三份导入文件是可直接落地的参考实现；跨版本迁移时，请重点核对触发器表达式语法与默认禁用项，即可快速复现这套 Oracle 监控体系。