企业官网建设流程全解析

本文围绕 Zabbix community-templates 仓库中的BALABIT-SNMPv2-Shell_Control_Box模板展开，系统讲解如何通过 SNMPv2 全面监控 Balabit Shell Control Box（SCB）——一款用于 SSH、HTTP、RDP、ICA、Telnet、VNC 等远程会话审计与访问控制的网络安防设备。读完本文，你将掌握模板的导入方法、以snmpwalk为起点的宏回填流程、网络接口/文件系统/CPU 三类发现规则、30 余项采集项与全套触发器的底层实现，以及部署排障的实战要点。

模板概览：BALABIT-SNMPv2-Shell_Control_Box

该模板的名称即BALABIT-SNMPv2-Shell_Control_Box，用途是"以 SNMP v2 对 Balabit Shell Control Box 产品进行监督"。它在 Zabbix 中同时承担两类监控职责：

• 通用主机健康监控：ICMP 连通性、SNMP 可用性、系统描述、主机名、进程数与在线用户数；
• 业务进程监控：对 SCB 上以scb_为前缀的六大协议代理进程（scb_http、scb_ica、scb_rdp、scb_ssh、scb_telnet、scb_vnc）以及indexerservice、indexerworker、workercontroller等核心服务进行状态、CPU 与内存的逐进程监督。

模板在仓库中提供三个 Zabbix 版本的文件，分布在同目录下的版本子目录中：

从导出文件的元数据看（5.4 YAML 第 1-3 行zabbix_export: version: '5.4'），三个版本均出自同一份 2021-11-21 的导出；5.4 与 6.0 的 YAML 内容基本一致，仅导出格式版本不同，而 5.0 使用 XML 格式、触发器采用旧式{last()}表达式语法。模板被归入主机组SECURITE，所有 SCB 服务进程采集项统一带有Application: Shell_Control_Box_Services标签（5.0 中为同名 application 分组），便于在 Zabbix 中按应用维度过滤和汇总。

导入模板

在 Zabbix Web 前端按配置（Configuration）→ 模板（Templates）→ 导入（Import）选择对应版本的 YAML/XML 文件即可完成导入。导入后注意两点：

1. 模板没有链接其他模板（README 的 "Template links" 一节明确注明 "There are no template links in this template"），因此不会自动引入网络接口、CPU 等公共模板，所有监控项均由本模板自包含；
2. 为监控主机挂接模板时，需确保主机配置了SNMP 接口，并正确设置{$SNMP_COMMUNITY}（团体名）与{$SNMP_PORT}（默认161）宏。

核心配置：为每个 scb_ 协议回填宏值

这是该模板最关键的部署步骤。模板对六大协议进程的识别，不是靠固定的进程名或 PID，而是靠HOST-RESOURCES-MIB 中hrSWRunParameters列存储的完整命令行字符串与宏值的精确匹配。README 给出了两步操作流程：

第一步：用 snmpwalk 提取每个协议的真实命令行字符串

在能访问 SCB 的管理机上执行：

snmpwalk | grep scb_

更精确的做法是直接遍历 HOST-RESOURCES-MIB 的进程参数表，只取每一行的参数列，避免无关行干扰：

snmpwalk -v 2c -c <community> <scb_ip> HOST-RESOURCES-MIB::hrSWRunParameters

输出中每一行形如：

HOST-RESOURCES-MIB::hrSWRunParameters.<index> = STRING: --as scb_ssh --threads 1500 --stack-size 256 ...

grep scb_即可过滤出scb_http、scb_ica、scb_rdp、scb_ssh、scb_telnet、scb_vnc六条真实命令行。

第二步：把字符串原样写入宏

将第一步得到的每条完整命令字符串，逐字复制（不能增删字符、不能调整参数顺序）填入对应的{$STRING_SERVICE_*}宏，例如{$STRING_SERVICE_SSH}←--as scb_ssh --threads 1500 ...。字符串与设备上实际参数不一致时，SNMP 表过滤将无法命中目标进程行，监控项会无数据，随之触发 "not running" 告警（详见下文触发器部分）。

宏清单与默认值

模板预置的 7 个宏及默认值如下（5.4 YAML 第 667-690 行macros段）：

从命令行参数命名可以推断其含义：--as指定 Zorp 应用名（即scb_*服务标识）；--threads为线程数（1500）；--stack-size为线程栈大小（256）；--process-mode safe-background表示以安全后台模式运行；--verbose 4为日志详细级别；--log-tags/--log-escape控制日志标签与转义输出；--uid zorp指定以zorp用户运行，--gid后应跟随组名。

需要特别留意：默认值只是示例。YAML 中 HTTP 宏以--gi结尾、TELNET 宏以--结尾，--gid后均未跟实际组名——这些默认值本身并不完整。这正是 README 反复强调"必须为每个协议获取真实字符串并回填宏"的原因：宏值只有在与设备真实hrSWRunParameters完全一致时才能命中进程行。

宏的底层作用机制：SNMP 表过滤

宏值是如何参与 OID 解析的？看 5.4 YAML 第 340-343 行 scb_ssh 状态项的snmp_oid：

HOST-RESOURCES-MIB::hrSWRunStatus["index","HOST-RESOURCES-MIB::hrSWRunParameters", "{$STRING_SERVICE_SSH}"]

从 OID 写法可以推断其解析逻辑：Zabbix 先在hrSWRunIndex表上建立行索引（第一个参数index），再指定过滤列hrSWRunParameters（第二个参数），最后用宏值{$STRING_SERVICE_SSH}（第三个参数）作为过滤条件，返回命中行的hrSWRunStatus值。也就是说，进程识别完全依赖"命令行参数列等于宏值"这一等值匹配，任何字符偏差都会导致该行被过滤掉。

同理，CPU 与内存项只是把返回列换成hrSWRunPerfCPU/hrSWRunPerfMem，过滤条件不变：

HOST-RESOURCES-MIB::hrSWRunPerfCPU["index","HOST-RESOURCES-MIB::hrSWRunParameters", "{$STRING_SERVICE_SSH}"] HOST-RESOURCES-MIB::hrSWRunPerfMem["index","HOST-RESOURCES-MIB::hrSWRunParameters", "{$STRING_SERVICE_SSH}"]

而indexerservice/indexerworker则改用可执行路径列hrSWRunPath做匹配（5.4 YAML 第 94 行）：

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

workercontroller又回到参数匹配，且因参数固定（含配置文件路径）直接写死为完整字符串（第 454 行）：

HOST-RESOURCES-MIB::hrSWRunPerfCPU["index","HOST-RESOURCES-MIB::hrSWRunParameters", "/usr/bin/workercontroller.py --config-file /etc/indexer/indexerworker.cfg"]

发现规则（Discovery Rules）：网络接口 / 文件系统 / CPU

模板内置三条 SNMP 发现规则，更新间隔均为 60 秒，为监控项原型（item prototype）提供动态实例：

| 规则名 | 类型 | 键 | 底层发现 OID | | ------ | ---- | -- | ------------ | | Network | SNMP agent |snmp.network.discovery|discovery[{#SNMPVALUE},IF-MIB::ifName]| | File System | SNMP agent |snmp.filesystem.discovery|discovery[{#SNMPVALUE},.1.3.6.1.2.1.25.2.3.1.3]（即hrStorageDescr） | | CPU | SNMP agent |snmp.CPU.discovery|discovery[{#SNMPVALUE},HOST-RESOURCES-MIB::hrProcessorLoad]|

discovery[{#SNMPVALUE},OID]是 Zabbix 标准的 SNMP 发现语法：第二个参数指定用于枚举的表列（如ifName、hrStorageDescr、hrProcessorLoad），发现的每个实例值写入宏{#SNMPVALUE}，Zabbix 同时提供{#SNMPINDEX}宏携带对应行索引，供原型项拼装 OID 使用。三条规则覆盖了 SCB 设备的接口清单、挂载存储与 CPU 拓扑，使监控项随设备实际配置自动增删，无需手工维护。

采集项全景

模板共定义33 个常规采集项 + 14 个 LLD 原型项，这里按功能分组列出（键名、类型与更新间隔均与 README 及 YAML 一致）。

scb_ 六大协议进程（18 项，更新间隔 60s）

每个协议各 3 项：Status（状态）、Perf CPU（CPU 用量）、Perf Memory（内存用量，单位为Kbytes，模板 description 明确标注 "Result in Kbytes"）。

索引服务与控制器（9 项，更新间隔 60s）

SCB 的索引子系统由indexerservice、indexerworker两个守护进程组成，另有一个 Python 实现的workercontroller（以/usr/bin/workercontroller.py --config-file /etc/indexer/indexerworker.cfg启动），三者各监控 Status、Perf CPU、Perf Memory 三个维度：

系统与可用性（6 项）

| 名称 | 键 | 类型 | 更新间隔 | 底层 OID / 说明 | | ---- | -- | ---- | -------- | ---------------- | | Ping Device |icmpping[,2]| Simple check | 30 | 两次 ICMP 探测 | | Snmp Availability |zabbix[host,snmp,available]| Zabbix internal | 60 | SNMP 可用性状态 | | Name Machine |SNMP-NameMachine| SNMP agent | 3600 |SNMPv2-MIB::sysName.0，同时写入资产（inventory）NAME 字段 | | System Description |SNMP-SysDescr| SNMP agent | 3600 |SNMPv2-MIB::sysDescr.0| | Nombre de Processus |SNMP-Number-Processus| SNMP agent | 60 |.1.3.6.1.2.1.25.1.6.0（hrSystemProcesses，进程总数） | | Nombre Utilisateurs Connectes |SNMP-Number-User-Connected| SNMP agent | 60 |.1.3.6.1.2.1.25.1.5.0（hrSystemNumUsers，在线用户数） |

LLD 原型采集项（14 项）

Network（8 项）——基于ifName发现每个接口：

| 名称 | 键 | 更新间隔 | OID | | ---- | -- | -------- | --- | | Interface [{#SNMPVALUE}] - IN Octets |SNMP-Interface-IN-Octets-[{#SNMPVALUE}]| 60 |IF-MIB::ifInOctets.{#SNMPINDEX}| | Interface [{#SNMPVALUE}] - MAC |SNMP-Interface-MAC-[{#SNMPVALUE}]| 3600 |IF-MIB::ifPhysAddress.{#SNMPINDEX}| | Interface [{#SNMPVALUE}] - MTU |SNMP-Interface-MTU-[{#SNMPVALUE}]| 3600 |IF-MIB::ifMtu.{#SNMPINDEX}| | Interface [{#SNMPVALUE}] - Operational Status |SNMP-Interface-Op-Status-[{#SNMPVALUE}]| 60 |IF-MIB::ifOperStatus.{#SNMPINDEX}| | Interface [{#SNMPVALUE}] - OUT Errors |SNMP-Interface-OUT-Errors-[{#SNMPVALUE}]| 60 |IF-MIB::ifOutErrors.{#SNMPINDEX}| | Interface [{#SNMPVALUE}] - OUT Octets |SNMP-Interface-OUT-Octets-[{#SNMPVALUE}]| 60 |IF-MIB::ifOutOctets.{#SNMPINDEX}| | Interface [{#SNMPVALUE}] - Speed |SNMP-Interface-Speed-[{#SNMPVALUE}]| 3600 |IF-MIB::ifSpeed.{#SNMPINDEX}| | Interface [{#SNMPVALUE}] - Type |SNMP-Interface-Type-[{#SNMPVALUE}]| 3600 |IF-MIB::ifType.{#SNMPINDEX}|

File System（3 项）——基于hrStorageDescr发现存储：

| 名称 | 键 | 类型 | 更新间隔 | OID / 公式 | | ---- | -- | ---- | -------- | ---------- | | File System {#SNMPVALUE} - Espace Alloue |SNMP-File-System-Space-Allocated-[{#SNMPVALUE}]| SNMP agent | 60 |.1.3.6.1.2.1.25.2.3.1.5.{#SNMPINDEX}| | File System {#SNMPVALUE} - Espace Utilise |SNMP-File-System-Space-Used-[{#SNMPVALUE}]| SNMP agent | 60 |.1.3.6.1.2.1.25.2.3.1.6.{#SNMPINDEX}| | File System {#SNMPVALUE} - Used Percentage |File-System-Space-Used-Percentage-[{#SNMPVALUE}]| Calculated | 60 |100*(last(//SNMP-File-System-Space-Used-[{#SNMPVALUE}])/last(//SNMP-File-System-Space-Allocated-[{#SNMPVALUE}]))|

其中 "Used Percentage" 是唯一的计算型项，由已用空间除以分配空间得到使用率百分比（0-100），作为磁盘告警的判定依据。

CPU（3 项）——基于hrProcessorLoad发现：

| 名称 | 键 | 更新间隔 | OID | | ---- | -- | -------- | --- | | CPU {#SNMPINDEX} - Name |SNMP-Name-CPU-[{#SNMPINDEX}]| 3600 |HOST-RESOURCES-MIB::hrDeviceDescr.{#SNMPINDEX}| | CPU {#SNMPINDEX} - Charge |SNMP-Charge-CPU-[{#SNMPINDEX}]| 60 |HOST-RESOURCES-MIB::hrProcessorLoad.{#SNMPINDEX}| | CPU {#SNMPINDEX} - Etat |SNMP-Etat-CPU-[{#SNMPINDEX}]| 60 |HOST-RESOURCES-MIB::hrDeviceStatus.{#SNMPINDEX}|

触发器与告警策略

模板的告警体系可以归纳为三类模式，共约 24 个触发器（部分来自 LLD 原型，随发现实例动态生成）。

服务进程的"双触发器"模式

对 9 个被监控进程（6 个 scb_ 协议进程 + indexerservice + indexerworker + workercontroller），每个 Status 项都挂两个触发器（以 scb_ssh 为例，见 5.4 YAML 第 349-359 行）：

两者的分工互补：

• 状态异常触发器：last(...)<>2。HOST-RESOURCES-MIB 的hrSWRunStatus以整型编码进程状态，从模板表达式可以推断作者把值2视为进程正常运行的标志——只要返回值不等于 2，就判定"进程存在但未正确运行"；
• 无数据触发器：nodata(...,70s)=1。当 SNMP 表过滤找不到匹配行（进程彻底消失、宏值不匹配、OID 无响应）时采集项无数据，超过 70 秒窗口即触发"进程未运行"。70s 窗口略大于 60s 更新间隔，可避免轮询抖动造成的误报。

其余 8 个进程照此模式各挂两个触发器，名称与键一一对应（scb_http、scb_ica、scb_rdp、scb_telnet、scb_vnc、indexerservice、indexerworker、workercontroller）。一个可见的小瑕疵是：5.4 YAML 中 scb_ssh 的 "not running" 触发器名称末尾多拼了scb_ssh字样（YAML 第 358 行），不影响表达式功能，仅告警标题略显冗余。

磁盘空间三级告警

File System 原型上的 "Used Percentage" 计算项按使用率设定了三级渐进告警（README Triggers 一节完整列出）：

即"已用空间占比 ≥90% / ≥95% / ≥99%"分别对应警告 / 一般 / 严重三级，逐级升级。

接口与连通性告警

ifOperStatus返回 0 表示接口 down（up(1)、down(2)之外，值为 0 通常代表未知/故障态，模板作者将其作为 DOWN 判定依据），触发 AVERAGE 告警；设备 ping 不通或 SNMP 不可用时，直接给出 HIGH 级告警。

实战要点与排障

1. 宏匹配是告警正确性的前提。若出现大量 "not running" 误报而进程实际存活，几乎可以断定是宏值与设备真实命令行不一致。此时回到设备上重新执行snmpwalk | grep scb_，把新抓取的字符串逐字回填。注意参数中的空格、引号、参数顺序都属于匹配内容。

2. 注意默认宏值的"残缺"。模板自带的{$STRING_SERVICE_HTTP}（以--gi结尾）、{$STRING_SERVICE_TELNET}（以--结尾）等默认值并不完整，导入后直接使用大概率无法命中进程行，务必用真实值覆盖。

3. 宏的作用域。宏可在模板级统一设置，也可在具体主机上覆写。当多台 SCB 设备的进程参数不同（例如线程数、日志级别调整过）时，在主机级分别设置{$STRING_SERVICE_*}即可做到"一模板多参数"，而无需复制模板。

4. 更新间隔与告警窗口。进程 Status 项更新间隔 60s、nodata 窗口 70s；接口、CPU、文件系统 LLD 规则同样为 60s。修改宏后，最迟一个轮询周期（60s）内生效。

5. 单位与数据类型。hrSWRunPerfMem返回的进程内存单位为 Kbytes（模板 description 明确注明 "Result in Kbytes"）；sysDescr、sysName、接口 MAC、CPU Name 等文本类采集项更新间隔长达 3600s 且关闭趋势存储，用于身份信息展示而非告警。

6. 版本差异。5.0 的 XML 采用旧式触发器表达式（如{last()}<>1、{nodata(70)}=1）与 application 分组；5.4/6.0 的 YAML 使用新式last(/模板/键)语法与 tag 标签（Application: Shell_Control_Box_Services）。若从 5.0 升级，触发器表达式会在导入时自动转换，行为语义不变。

小结

BALABIT-SNMPv2-Shell_Control_Box 模板展示了 Zabbix 监控"命令行参数敏感型"网络设备的典型范式：通过snmpwalk采集真实进程参数 → 回填宏 → 借助 HOST-RESOURCES-MIB 的hrSWRunParameters/hrSWRunPath表过滤精准定位业务进程 → 以状态 + 无数据双触发器保证告警可靠性，同时用三条 LLD 规则覆盖接口、文件系统与 CPU 的自动发现。理解这一"宏驱动进程匹配"机制，不仅能正确部署本模板，也能为同类基于 HOST-RESOURCES-MIB 的进程监控需求提供可复用的设计思路。若需进一步核对实现细节，可直接查阅 5.4 模板 YAML 与 5.0 模板 XML 的原始导出。