企业官网建设流程全解析

导读

本文围绕 Zabbix 社区模板仓库（community-templates）中 Network Appliances 分类下的BALABIT-SNMPv2-Shell_Control_Box模板展开，讲解如何用 SNMP v2 对 One Identity（原 Balabit）出品的 Shell Control Box（SCB，堡垒机/会话管理网关）进行进程级监控。SCB 的核心价值在于会话审计与特权访问管理，其可用性直接依赖 SSH、Telnet、RDP、VNC、ICA、HTTP 等协议的代理进程是否健康运行，因此这套模板以HOST-RESOURCES-MIB为数据源，逐一对每个协议服务进程做"状态 + CPU + 内存"三维监控，并辅以接口、文件系统、CPU 的自动发现（LLD）与分级告警。读完本文，你将掌握：模板的完整宏配置流程（含snmpwalk取证方法）、三类 LLD 发现规则的底层 OID 结构、全部监控项与触发器语义，以及 5.0/5.4/6.0 三个版本文件的差异与导入方式。

模板定位与监控对象

模板的官方描述（见 6.0/README.md）为：Template for supervise, with SNMP v2, the product: BALABIT Shell Control Box，即面向 SCB 设备的 SNMPv2 监管模板。从模板实现看，它监控的不只是"设备活着没有"，而是深入到SCB 内部进程：

• 六个按协议命名的代理进程scb_http、scb_ica、scb_rdp、scb_ssh、scb_telnet、scb_vnc——这些是 SCB 中承载各类远程访问会话的 zorp 代理实例；
• 三个索引/后台服务indexerservice、indexerworker、workercontroller——负责会话索引与检索链路；
• 基础层信息：进程总数（SNMP-Number-Processus）、在线用户数（SNMP-Number-User-Connected）、系统描述（sysDescr）、主机名（sysName）、SNMP 可用性与 ICMP 可达性。

所有协议代理进程在模板中统一归属Shell_Control_Box_Services标签（6.0 版）或同名 Application 分组（5.0 版），便于在 Zabbix 中按业务维度聚合展示。

模板的工作原理：SNMPv2 + HOST-RESOURCES-MIB

从 6.0 模板 YAML 可以清晰看到，进程监控并未使用自定义私有 MIB，而是完全复用标准HOST-RESOURCES-MIB（RFC 2790）的三张表：

以indexerservice为例，模板中的三个监控项分别使用（见 YAML 第 92-123 行）：

HOST-RESOURCES-MIB::hrSWRunPerfCPU["index","HOST-RESOURCES-MIB::hrSWRunPath", "/usr/bin/indexerservice"] HOST-RESOURCES-MIB::hrSWRunPerfMem["index","HOST-RESOURCES-MIB::hrSWRunPath", "/usr/bin/indexerservice"] HOST-RESOURCES-MIB::hrSWRunStatus["index","HOST-RESOURCES-MIB::hrSWRunPath", "/usr/bin/indexerservice"]

其匹配逻辑是：在hrSWRunTable中先按hrSWRunPath定位可执行文件，再回填索引。对于 SCB 上多个由同一 zorp 二进制拉起的协议代理（scb_ssh、scb_rdp……），单靠路径无法区分，因此模板改用hrSWRunParameters（启动参数）作为匹配键，把整条启动命令行塞进 OID 索引——这正是本文后面要重点讲解"宏"的根因：不同环境里协议代理的启动参数不同，必须用宏承载、按环境注入。

内存监控项的描述明确标注为Result in Kbytes（hrSWRunPerfMem的原始单位），CPU 项则为累积 CPU 时间，可据此绘制趋势图判断会话代理是否持续消耗资源。

仓库目录结构与导入方式

该模板在仓库中按 Zabbix 大版本分目录维护（见 模板根目录）：

三个版本导出日期均为 2021-11-21，监控项与触发器内容一致，差异主要在导出格式与组织方式：5.0 的 XML 使用<applications>声明Shell_Control_Box_Services应用组，6.0 的 YAML 改用tags打标（见 YAML 第 97-101 行）；6.0 模板本身还带 UUID（模板87026011d66b46f6bd17ad26c8e7e110，组SECURITE的 UUID 为7fae1993c5024ce6b6d551a2bdfe6c04）。

导入方式：在 Zabbix Web 前端进入Data collection → Templates → Import，选择与你 Zabbix 版本匹配的目录（如 6.0 版选6.0/template_balabit-shell_control_box_snmp.yaml）上传即可；导入后模板归属于名为SECURITE的主机组。随后将 SCB 设备加入监控（Configuration → Hosts），选择该模板并完成宏配置。

部署前置：在 SCB 上启用 SNMP

模板的监控数据全部来自 SNMP 轮询，因此在 Zabbix 侧导入模板之外，还需确保 SCB 设备满足：

1. SNMP 服务已启用且监听于可访问的端口（模板宏默认端口为161，见下文宏表）；
2. SNMP 版本为 v2c，并配置好只读 community（读权限即可，模板只用 GET/DISCOVERY，不需要写权限）；
3. HOST-RESOURCES-MIB 可用。模板的所有进程监控项、SNMP-Number-Processus（OID.1.3.6.1.2.1.25.1.6.0）、在线用户数（OID.1.3.6.1.2.1.25.1.5.0）、文件系统与 CPU 发现都依赖该 MIB，这是 Linux/类 Unix 系统上 net-snmp 默认加载的标准 MIB，一般无需额外配置；
4. 防火墙放行 Zabbix server/proxy 到 SCB 的 UDP 161 端口。

导入模板后，可通过监控项SNMP-SysDescr（SNMPv2-MIB::sysDescr.0，更新间隔 3600 秒）与SNMP-NameMachine（SNMPv2-MIB::sysName.0，3600 秒）确认 SNMP 联通性——这两个项能正常取值，说明 MIB 解析链路通畅。

关键配置：按协议定制宏

这是整个模板最核心的配置步骤。模板要求为每个被监管的协议代理设置一个对应的{$STRING_SERVICE_*}宏，值是该协议代理进程的真实启动命令行。原因如前所述：进程定位靠hrSWRunParameters精确匹配，命令行写错一个字符，对应监控项就会取不到数据（No data），从而触发"服务未运行"告警。

第一步：snmpwalk 抓取进程启动参数

原文档给出的取证命令是（在可对 SCB 执行 SNMP 轮询的机器上运行）：

snmpwalk -v2c -c <community> <scb_ip> | grep scb_

其中<community>是 SCB 上配置的只读 community，<scb_ip>是 SCB 的管理地址。输出会列出HOST-RESOURCES-MIB::hrSWRunParameters下所有进程的启动参数，从中挑出形如--as scb_ssh ...的完整命令行，逐条记录——这就是每个{$STRING_SERVICE_*}宏的取值来源。

也可以更精确地限定 OID 子树，减少输出噪音：

snmpwalk -v2c -c <community> <scb_ip> HOST-RESOURCES-MIB::hrSWRunParameters | grep scb_

第二步：宏清单与默认值

拿到真实参数后，在模板宏或主机宏层面逐个填入。模板自带的宏及默认值完整清单如下（与 6.0 README 宏表 及 YAML 第 667-690 行 一致）：

配置建议：{$SNMP_COMMUNITY}按主机维度设置（每台 SCB 的 community 可能不同），六个{$STRING_SERVICE_*}按部署环境设置（模板级或主机级均可）。若你的 SCB 未启用某种协议（如 TELNET），可将对应宏清空/不设，避免无谓的 No data 告警。

宏参数语义

默认值实际是一段 zorp 守护进程的经典命令行（SCB 的会话代理基于 zorp 框架），理解其语义有助于判断哪些字段需要按环境调整：

实践要点：宏值必须与snmpwalk抓到的逐字符一致，尤其是尾部参数（注意 HTTP 宏默认值以--gi结尾、TELNET 宏以--结尾，与其余宏的--gid不同）——这些差异恰恰反映了真实环境的多样性，也提醒我们"以实测为准、不要照抄默认值"。

三条发现规则（LLD）

模板通过三条 SNMP 发现规则自动发现设备上的网络接口、文件系统与 CPU，并批量创建监控项。三者均为SNMP agent类型、更新间隔 60 秒（详见 YAML 第 516-666 行）：

Zabbix 的 SNMP LLD 规则使用discovery[{#SNMPVALUE},<OID>]语法：先 GETNEXT 遍历指定 OID 子树，把每个实例的值作为{#SNMPVALUE}宏、把实例的索引部分作为{#SNMPINDEX}宏，随后代入各原型项的 OID 与键。注意 Network 发现遍历的是IF-MIB::ifName（接口名），而 File System 遍历的是hrStorageDescr（存储描述），两者"取值列"不同，决定了{#SNMPVALUE}呈现的是接口名还是分区名，也直接体现在下文原型监控项的命名中（Interface [{#SNMPVALUE}]与File System {#SNMPVALUE}）。

监控项全景

模板共含 33 个固定监控项 + 若干 LLD 原型项。固定项可归为四组（命名、键、更新间隔均来自 6.0 README Items 表 与 YAML items 段）：

1. 协议服务进程（Supervising scb_*）

对scb_http、scb_ica、scb_rdp、scb_ssh、scb_telnet、scb_vnc六个协议代理，各建三个监控项（更新间隔均 60 秒）：

六个协议 × 三项 = 18 个监控项，全部打Application: Shell_Control_Box_Services标签。

2. 后台服务进程（indexerservice / indexerworker / workercontroller）

会话索引与检索链路的三个进程，同样按 Status / Perf CPU / Perf Memory 各建三项：

注意前两个用可执行路径匹配，workercontroller因是 Python 脚本（需带--config-file参数才能唯一定位）改用参数列匹配。这一组共 9 个监控项。

3. 基础健康与系统信息

4. LLD 原型项（接口 / 文件系统 / CPU）

Network 原型（8 个），随snmp.network.discovery生成，{#SNMPVALUE}为接口名：

File System 原型（3 个），随snmp.filesystem.discovery生成：

计算项是告警的唯一数据源：只要"已用/已分配"比例一致，百分比便不受hrStorageAllocationUnits单位差异影响，这一设计让文件系统告警天然跨设备通用。

CPU 原型（3 个），随snmp.CPU.discovery生成：

触发器与告警体系

模板的告警分为两类：固定监控项上的静态触发器与 LLD 原型上的原型触发器。以下为完整清单（表达式以 6.0 YAML 为准）：

静态触发器（固定监控项）

每个进程 Status 项都配了一对互补触发器，这是本模板告警设计的精髓：

• 状态异常触发：last(...)<>2。hrSWRunStatus按 HOST-RESOURCES-MIB 标准枚举为 running(1)、runnable(2)、notRunning(3)、invalid(4)，<>2即"进程不在可运行状态"，用于捕获进程僵死、退出码异常等场景；
• 无数据触发：nodata(...,70s)=1。Status 项更新间隔为 60 秒，70 秒无新数据说明进程定位失效（多半是宏值与实际命令行不匹配）或 SNMP 取数中断，属于典型的"配置漂移"快速探测。

原型触发器（LLD）

文件系统按"使用率 ≥90% 警告 → ≥95% 严重 → ≥99% 高"三级递进告警；接口 DOWN 判断ifOperStatus为 0（up(1) 之外即为 down）。原文档 Triggers 表同时列出了同名触发器的 LLD 变体（(LLD)后缀行），即告警实际由原型在每次发现后生成，随接口/分区增删自动收敛。

版本差异与文件说明

该模板在仓库中并存三个版本（见 模板根目录）：

• 5.0 XML：适用于 Zabbix 5.0 系列，监控项通过<applications>归属Shell_Control_Box_Services应用组，触发器表达式使用{last()}/{nodata(70)}简写；
• 5.4 YAML：Zabbix 5.4 原生 YAML 导出格式，结构与 6.0 一致；
• 6.0 YAML：Zabbix 6.0 格式，应用组改为Application: Shell_Control_Box_Services标签，触发器表达式升级为全限定形式（last(/BALABIT-SNMPv2-Shell_Control_Box/<key>)）。

三者的宏、监控项、发现规则与告警逻辑完全一致，请按你的 Zabbix 大版本选择对应目录导入，避免格式不兼容。

常见问题与调优建议

1. 进程监控项全部 No data：几乎可以确定是{$STRING_SERVICE_*}宏与真实启动命令行不一致。回到snmpwalk | grep scb_重新取证，逐字符比对后更新宏。
2. 个别协议监控项 No data，其余正常：该协议代理可能未启用，或启动参数里含特殊字符（空格、引号）导致 OID 索引编码差异；核对hrSWRunParameters的实际输出。
3. 误报 "not running"：nodata(...,70s)只给 70 秒窗口，若 SNMP 轮询偶尔超时（尤其大流量 SCB 上 UDP 丢包），可适当放宽——但需注意这是模板内嵌常量，调整需修改模板触发器或覆盖触发器。
4. 文件系统告警基线：默认 90%/95%/99% 三级阈值面向通用场景；对日志/索引分区可考虑在主机级覆盖原型触发器阈值。
5. 高频轮询成本：协议代理类监控项（18 个）与 LLD 原型全部为 60 秒间隔，加上接口/文件系统/CPU 原型，单台 SCB 轮询量不小。若设备数量多，可将 Status 类项保留 60s、Perf 类项放宽到 120s 以降低 Zabbix server 负担。
6. 资产联动：SNMP-NameMachine已绑定资产清单的 NAME 字段（inventory_link: NAME），配合 SysDescr 可让 SCB 在资产模块自动呈现主机名与设备描述。

小结

BALABIT-SNMPv2-Shell_Control_Box 模板的价值在于把 SCB 这类"黑盒"安全网关的进程级健康状态透明化：以标准 HOST-RESOURCES-MIB 为底座，用hrSWRunParameters精确匹配每个协议代理，配合 LLD 自动覆盖接口、文件系统与 CPU，最终通过"状态 ≠ runnable + 70s 无数据"双触发器实现会话代理故障的快速感知。部署时的唯一关键动作，是依据snmpwalk实测结果正确配置六个{$STRING_SERVICE_*}宏——这也是该模板能在不同 SCB 环境中即插即用的前提。