本篇技术指南围绕 Zabbix 社区模板仓库中的template_sap_backup_tenant_systemdb（SAP Backup）展开，讲解如何基于 shell script + hdbsql + Zabbix agent UserParameter 实现对 SAP 备份执行状态（SYSTEMDB 与 TENANT）的自动化监控。读完本文，你将掌握该模板的宏定义、监控项键结构、值映射与告警触发器设计，并能独立完成模板导入、参数配置与配套采集脚本的落地部署。

模板定位与技术路线

template_sap_backup_tenant_systemdb是 Zabbix Community Templates 仓库中Applications/Backup分类下的一个应用级模板（README），其设计目标非常聚焦：监控由 SAP 自身执行的备份作业。原文档明确列出三个核心监控维度：

• 备份执行的日期/时间（Data da execucão do backup）
• SYSTEMDB 备份状态
• TENANT（租户库）备份状态

该模板不依赖 SNMP、不依赖 JMX，而是采用一条非常典型的"被动式 agent"技术路线：在 SAP 主机上放置一个 shell 脚本，通过 SAP HANA 自带的命令行客户端hdbsql查询备份目录（backup catalog），再把结果通过 Zabbix agent 的UserParameter机制暴露给 Zabbix server 轮询。整个项目由 Zabbix Brasil Telegram 社区用户 Wilson Fernandes 与 Eduardo Freitas 发起，作者为 wilsonwers。

在仓库中，该模板同时提供了面向不同 Zabbix 大版本的三套导出文件，内容完全一致、仅是导出格式不同：

从 YAML 导出文件头（zabbix_export: version: '5.4'，日期2021-11-21）可以看出模板发布于 2021 年底，属于该模板最早的一批社区实现之一。

模板宏（Macros）定义与含义

模板通过三个文本宏（Text macro）把与具体环境相关的信息全部参数化，链接模板到主机后只需覆盖宏即可适配不同 SAP 系统。原文档的宏定义表如下：

在 5.4 YAML 导出 的macros段中可以看到同样的默认值定义，即{$BCO}=PRD、{$ID}=00、{$PASS}=passwd。结合监控项键check_backup[{$ID},{$PASS},{$BCO},...]的传参位置可以推断其职责：

• {$ID}：SAP HANA 实例号（instance number），默认00。该值决定 hdbsql 连接端口（如 SYSTEMDB 端口一般为3<ID>13，实例 00 即 30013），也常用于脚本拼接连接参数；
• {$PASS}：执行备份查询所需的口令，默认passwd，实际部署时应通过主机/模板级宏覆盖为真实凭据；
• {$BCO}：业务/系统标识前缀，默认PRD，在监控项名称中作为前缀出现（如{$BCO} - STATUS INDEXSERVER TENANT），同时作为脚本参数传入，用于区分被监控的 SAP 系统或备份配置。

安全提示：{$PASS}以明文宏形式存储于模板与主机配置中。建议在主机级（而非模板级）覆盖该宏，并限制 Zabbix server 与 agent 之间的传输链路；若追求更高安全性，可改为让脚本从受保护文件中读取凭据，宏只负责传递标识性参数。

监控项（Items）结构与键约定

模板共采集 6 个监控项，全部为Zabbix agent类型（被动模式）。原文档给出的监控项清单如下：

所有监控项共用同一个 UserParameter 键check_backup，通过五个位置参数区分不同查询，其约定可以拆解为：

check_backup[<实例号>, <密码>, <系统标识>, <查询类型>, <服务类型>]

• 第 4 个参数（查询类型）：backup表示返回备份状态（0/1），backup_last表示返回最近一次备份的日期/时间信息；
• 第 5 个参数（服务类型）：nameserver对应 SYSTEMDB（nameserver 是 HANA 系统的主控服务，SYSTEMDB 即由其承载），indexserver与xsengine对应 TENANT 租户库（indexserver 承载行/列存储，xsengine 承载扩展引擎）。

从 5.4 YAML 的完整定义可以进一步看到两类监控项的属性差异：

• STATUS 类（backup）：delay: 3600s（每小时采集一次），trends: 180d（保留 180 天趋势），数值类型为默认的数字类型，并挂接SAP_BACKUP值映射；
• LAST 类（backup_last）：delay: 21600s（每 6 小时采集一次），trends: '0'（不保存趋势），value_type: CHAR（字符串类型，用于承载日期/时间文本），同样挂接SAP_BACKUP值映射。

两类监控项均带有标签Application: SAP Backup，并隶属于SAP Backup应用（application）。

值映射：0 = OK，1 = ERRO

为了把脚本返回的原始数值翻译成人类可读的状态，模板定义了一个名为SAP_BACKUP的值映射（valuemap），在 5.4/6.0 的 YAML 与 5.0 的 XML 导出中均有完整定义：

即约定：0 表示备份成功（OK），1 表示备份失败（ERRO）。该值映射被全部 6 个监控项引用，因此在"最新数据"界面中看到OK/ERRO字样时，其语义即对应最近一次备份作业的成功与否。

告警触发器：备份失败即 DISASTER

值得注意的一个细节是：README 文档中写着"There are no triggers in this template"，但实际导出文件（XML/YAML）中明确包含 3 个触发器——这是 README 与导出文件之间的一处不一致，部署时请以导出文件为准。三个触发器全部针对 STATUS 类监控项：

（5.0 XML 中表达式以{last()}>0的简写形式出现，语义相同。）

表达式逻辑非常直白：只要对应服务最近一次返回的备份状态值大于 0（即值映射中的ERRO/1），立即触发告警，且优先级直接拉满为DISASTER（灾难级）——这正是备份监控的应有姿态：备份失败是最高等级事件，需要在第一时间告警。配合 STATUS 监控项每小时一次的采集频率，最坏情况下备份失败后 1 小时内即可被发现。

内置图形：{$BCO} - SAP Backup

模板还内置了一个名为{$BCO} - SAP Backup的图形（graph），将三个 STATUS 类监控项叠加在同一张图上（YAML 定义）：

由于 STATUS 监控项是 0/1 数值，该图形以三条渐变曲线直观呈现 SYSTEMDB（nameserver）与两个 TENANT 服务（indexserver、xsengine）的备份状态在时间轴上的变化，任何一条线跳升到 1 即代表对应服务发生备份失败。

部署实战：脚本 + hdbsql + UserParameter 的完整落地

原文档明确说明了整套方案的技术构成——shell script + hdbsql + Zabbix agent UserParameter。虽然仓库未附带脚本本身（脚本由社区在 Zabbix Brasil Telegram 群组中分享），但模板的键约定已经把脚本的输入输出契约定义得非常清楚。下面给出与模板键约定完全一致的参考实现思路。

第 1 步：在 SAP 主机上放置采集脚本

脚本接收与监控项键一一对应的参数，用hdbsql查询 HANA 备份目录，并按查询类型输出。参考实现骨架如下：

#!/bin/bash # check_backup.sh - SAP HANA 备份状态采集脚本（参考实现） # 用法: check_backup.sh <实例号> <密码> <系统标识> <backup|backup_last> <nameserver|indexserver|xsengine> ID=$1 PASS=$2 BCO=$3 TYPE=$4 SERVICE=$5 # SYSTEMDB 端口约定: 3<实例号>13，实例 00 即 30013 HDBSQL="hdbsql -n localhost:3${ID}13 -u SYSTEM -p ${PASS} -d SYSTEMDB -j -o " case "${TYPE}" in backup) # 查询最近一次备份作业状态: 成功输出 0，失败输出 1 STATUS=$( ${HDBSQL} "SELECT ... FROM M_BACKUP_CATALOG WHERE ..." ) if [ "${STATUS}" = "SUCCESSFUL" ]; then echo 0 else echo 1 fi ;; backup_last) # 输出最近一次备份的日期/时间字符串 ${HDBSQL} "SELECT TOP 1 BACKUP_ID, START_TIME, STATE_NAME FROM M_BACKUP_CATALOG ORDER BY START_TIME DESC" ;; esac

说明：以上脚本为与本模板键约定一致的一种参考实现思路，具体 SQL 需根据实际 HANA 版本（如M_BACKUP_CATALOG系统视图的列结构）与备份策略调整；hdbsql所在目录、-j等参数亦需按现场环境确认。脚本中"查询类型"（backup/backup_last）与"服务类型"（nameserver/indexserver/xsengine）的分支设计，正是为了匹配模板中 6 个监控项的调用形态。

第 2 步：注册 UserParameter

在 Zabbix agent 配置目录（Linux 下通常为/etc/zabbix/zabbix_agentd.conf.d/）新建 userparameter 配置文件，内容如下：

UserParameter=check_backup[*],/usr/local/bin/check_backup.sh $1 $2 $3 $4 $5

Zabbix agent 收到形如check_backup[00,passwd,PRD,backup,indexserver]的请求时，会把方括号内的 5 个参数依次传给脚本，脚本输出即作为监控项的值回传 server。这正好与模板监控项的键check_backup[{$ID},{$PASS},{$BCO},backup,indexserver]一一对应——宏展开后填入的正是 UserParameter 的参数位。

配置完成后，使用zabbix_get -s <SAP主机> -k "check_backup[00,passwd,PRD,backup,nameserver]"即可在 Zabbix server 侧手动验证取值链路是否打通。

第 3 步：导入模板并挂接主机

1. 从仓库下载对应 Zabbix 版本的导出文件（5.0 用 XML，5.4/6.0 用 YAML）；
2. 在 Zabbix Web 界面数据采集 → 模板 → 导入，选择下载的文件完成导入（模板名称为SAP Backup，归入Templates组）；
3. 创建或编辑 SAP 主机，在模板页签链接SAP Backup；
4. 在主机级宏页签覆盖{$BCO}（如实际系统标识）、{$ID}（实例号）与{$PASS}（真实口令），并确保主机使用被动模式 agent 接口；
5. 等待若干采集周期后，在最新数据中即可看到 6 个监控项，STATUS 类显示OK/ERRO（经SAP_BACKUP值映射翻译），LAST 类显示最近备份的日期/时间文本。

采集频率与告警时效设计小结

模板对两类监控项采用差异化采集频率，值得在实际部署中体会其设计意图：

• STATUS（backup）：3600s（1 小时）一次——备份状态属于低频变化数据，小时级轮询足够，且配合 180 天趋势保留可以回溯历史状态；
• LAST（backup_last）：21600s（6 小时）一次——最近备份时间戳只需低频刷新，且trends: 0不保存趋势、CHAR字符串存储，避免无意义的数据膨胀。

告警则完全由 STATUS 类监控项驱动，>0即触发 DISASTER，保证"失败必告警、告警即最高级"。

与仓库中其他 SAP 模板的分工

社区模板仓库中还收录了另外两个 SAP 相关模板，与本模板恰好形成互补：

• template_sap_host_agent：基于 SAP Host Agent，覆盖主机层面的可用性、服务与资源监控；
• template_sap_process：监控 SAP 关键进程/服务的存活状态（SAP Availability Linux）。

本模板则专注于备份结果这一数据保护维度：备份是否执行、执行是否成功、最近一次备份发生在何时。三者结合，即可拼出一套覆盖"进程存活 → 主机健康 → 备份成功"的完整 SAP 运维监控闭环。若在 Production 环境中同时使用，建议将本模板与其他 SAP 模板一并链接到同一主机，并统一规划宏命名与告警接收人。

小结

template_sap_backup_tenant_systemdb是一个体量精简但设计清晰的 Zabbix 社区模板：它用 3 个宏参数化环境差异，用 6 个监控项（3 个状态 + 3 个最近时间）覆盖 SYSTEMDB 与 TENANT 的备份监控需求，用SAP_BACKUP值映射统一 0/1 语义，并用 3 个 DISASTER 级触发器保证备份失败即时可见。其"shell script + hdbsql + UserParameter"的实现路径不依赖任何商业插件，完全基于 SAP HANA 原生工具链，非常适合在已有 Zabbix 与 SAP HANA 的混合环境中快速落地，作为备份数据保护的最后一道自动化防线。