本指南围绕 Zabbix Community Templates 仓库中的template_checkpoint_fw-1_interfaces模板展开，讲解如何通过「外部脚本发现 + SNMP 采集」的组合方式，对 Checkpoint（Check Point）防火墙的接口级包过滤统计（Accept / Drop / Reject）进行自动化监控。读完本文，你将掌握该模板的完整部署前置条件、发现规则与监控项原型的底层原理，并能结合仓库源码文件（XML / YAML）独立完成导入、配置与验证。

模板定位：专注接口层包过滤统计

CheckPoint FW-1 Interfaces模板的核心用途，用模板自身的 Overview 一句话概括就是："Use this template to monitor Checkpoint firewalls interfaces and packet filtering."（见 5.4/6.0 版 README）。

它不监控 CPU、内存或 HA 状态——那是同目录下 CheckPoint FW-1 模板 的职责（该模板采集svnVersion、fwModuleState、fwInstallTime、haWorkMode、fwNumConn、内存及多核 CPU 时间等）。本模板只做一件事：通过低级别发现（LLD）自动枚举防火墙上的所有接口，并为每个接口采集 8 个包过滤计数器，从而回答"流量被接受了多少、被丢弃了多少、被拒绝了多少"这类防火墙日常运维的核心问题。

模板位于仓库的Network_Devices/Checkpoint/分类下，提供三个 Zabbix 版本的导入文件：

三个版本的逻辑完全一致，5.4 与 6.0 的 YAML 文件在 5.4 版模板定义 与 6.0 版模板定义 中逐项对应，仅序列化格式不同。

工作原理：外部脚本发现 + SNMP 原型采集

整个模板只包含一条发现规则和 8 个监控项原型，但它的数据链路却涉及三个层次：

1. 外部脚本发现（External check）：Zabbix Server 周期调用advsnmp.discovery外部脚本，对防火墙执行 SNMP 遍历，输出 JSON 格式的 LLD 数据（发现哪些接口）；
2. SNMP 原型采集（SNMP agent）：对每个被发现的接口，根据原型定义用 CHECKPOINT-MIB 中的 OID 轮询对应计数器；
3. 预处理（CHANGE_PER_SECOND）：将 SNMP 返回的累计计数器转换为每秒变化率（速率），再送入图形展示。

其中advsnmp.discovery是本模板（以及同目录多数 Checkpoint 模板）共用的外部脚本，其出处记录在 5.0 版 additional_info.txt 中（Simon Kowallik 的 Zabbix-Addons 项目，需自行下载部署到 Zabbix Server 的 ExternalScripts 目录）。该脚本的存在意义在于：Checkpoint 的接口表索引并非普通ifIndex，无法用 Zabbix 内置 SNMP LLD 规则直接解析，必须借助这个专门的外部脚本把 OID 索引拆解成多个宏（{#ADVSNMPVALUE}、{#ADVSNMPINDEX1}、{#ADVSNMPINDEX2}等），模板再基于这些宏生成监控项原型。

发现规则：Interfaces Discovery

模板中唯一的发现规则定义如下（来自 5.0 README 与 5.0 XML）：

Key 的四个参数逐一拆解：

• {HOSTNAME}：Zabbix 自动替换为当前主机的名称，脚本据此定位目标防火墙；
• "-v2c -c{$SNMP_COMMUNITY}"：传给底层 SNMP 工具的选项，-v2c表示 SNMPv2c，-c{$SNMP_COMMUNITY}使用主机级用户宏{$SNMP_COMMUNITY}作为团体字符串（Zabbix 内置同名宏默认值为public，可在主机或模板上覆盖）；
• 1.3.6.1.4.1.2620.1.1.25.5.1.2：要遍历的 OID。1.3.6.1.4.1.2620是 Check Point 的私有企业号前缀，.1.1.25.5.1.2落在 fw1 产品分支下的接口统计表区域，即防火墙接口级计数器表；
• 1.3：索引拆分定义。从 5.0 XML 的snmp_oid使用{#ADVSNMPINDEX2}可以推断，脚本按该参数把完整 OID 索引拆成两段：{#ADVSNMPINDEX1}（1 个子标识符）与{#ADVSNMPINDEX2}（3 个子标识符），后者被模板用作原型 SNMP OID 的索引部分。

发现出的每个接口同时产出{#ADVSNMPVALUE}（完整索引后缀）与{#ADVSNMPINDEX2}（3 段子索引），分别服务于监控项命名和 OID 构造。

部署前置条件

在导入模板之前，需要依次满足以下条件（均来自模板 Overview 与仓库文件）：

1. 防火墙侧开启 SNMP

在 Check Point GAiA / SmartConsole 中启用 SNMP 代理，并配置与{$SNMP_COMMUNITY}一致的团体字符串（默认模板期望为public，生产环境建议自定义并在 Zabbix 主机宏中覆盖）。

2. Zabbix Server 安装 CHECKPOINT-MIB

模板中的 SNMP 监控项直接引用CHECKPOINT-MIB::fwAcceptBytesIn这类符号 OID（见 5.0 XML），因此CHECKPOINT-MIB（chkpnt.mib）必须正确安装到 Zabbix Server 的 MIB 目录（Overview 中明确说明）。安装后可借助snmpwalk手工验证，例如：

snmpwalk -v2c -c public -m CHECKPOINT-MIB <防火墙IP> 1.3.6.1.4.1.2620.1.1.25.5.1.2

3. 部署 advsnmp.discovery 外部脚本

将advsnmp.discovery脚本放入 Zabbix Server 配置的 ExternalScripts 目录，并保证运行 Zabbix Server 的系统用户有执行权限。部署完成后可在服务器本机做一次冒烟测试：

advsnmp.discovery <防火墙主机名> "-v2c -c public" 1.3.6.1.4.1.2620.1.1.25.5.1.2 1.3

正常输出应为 JSON 数组，每个元素包含{#ADVSNMPVALUE}、{#ADVSNMPINDEX1}、{#ADVSNMPINDEX2}等字段。

4. 创建值映射 "Checkpoint standard status"

Checkpoint 模板集合要求预先创建名为"Checkpoint standard status"的值映射，映射关系固定为：

在 Zabbix 前端「管理 → 一般 → 值映射」中创建即可。虽然本模板自身的监控项未直接使用该映射（README 中 Macros used 与 Template links 均为空），但它属于整个 Checkpoint 模板集（如template_checkpoint_fw-1的 HA/状态类监控项）的公共依赖。

5. 导入模板并关联主机

• Zabbix 5.0：导入 5.0/XML；
• Zabbix 5.4 / 6.0：分别导入 5.4/YAML 或 6.0/YAML。

导入后把模板链接到代表防火墙的主机，确认主机上配置了 SNMP 接口（IP/端口 161）以及正确的{$SNMP_COMMUNITY}宏值。模板归属Templates组，监控项归属应用（Application）Checkpoint FW-1（5.0 XML 中以<applications>声明，5.4/6.0 YAML 中以标签Application: Checkpoint FW-1体现）。

监控项原型：8 个接口级计数器

发现规则生成接口后，每个接口自动实例化 8 个监控项（README 的 Items collected 表与 5.0 XML 的item_prototypes完全一致）：

计数器语义

从命名可以清晰对应 Checkpoint 包过滤的三种处置结果，均为入站（In）/出站（Out）双向：

• Accept：被防火墙策略接受并放行的流量——fwAcceptBytesIn/Out是字节计数，fwAcceptPcktsIn/Out是包计数；
• Drop：被防火墙静默丢弃的包（不回复任何报文），fwDropPcktsIn/Out；
• Reject：被防火墙拒绝并主动回复 RST/ICMP 的包，fwRejectPcktsIn/Out。

其中Drop与Reject的比值是判断"防火墙是否在拦截异常流量、策略是否过严"的常用观察点。

关键实现细节（源码级）

对照 5.0 XML（5.4/6.0 YAML 中逐项相同）可以看到每个原型共有的三处实现：

1. 值类型为 FLOAT：8 个原型的<value_type>均为FLOAT，为后续做速率计算预留数值精度；
2. 预处理 CHANGE_PER_SECOND：每个原型都挂载了<preprocessing><step><type>CHANGE_PER_SECOND</type></step></preprocessing>。SNMP 返回的字节/包计数是自设备启动以来持续累加的计数器，该步骤把"两次取值之差/时间差"换算为每秒速率，因此图形和告警表达式拿到的直接就是 bps / pps 量纲；
3. OID 引用 {#ADVSNMPINDEX2}：原型 OID 形如CHECKPOINT-MIB::fwAcceptBytesIn.{#ADVSNMPINDEX2}，接口索引由发现脚本按1.3拆分规则注入，从而保证每个接口实例指向正确的表行。

轮询间隔 120 秒，发现间隔 900 秒——后者是前者整数倍，符合 Zabbix 对 LLD 与实例采集节奏的常规搭配。

图形原型：Filtering for interface

每个被发现的接口还会自动生成一张名为"Filtering for interface {#ADVSNMPVALUE}"的图形（graph prototype），把 8 个计数器按流量方向与处置结果分组展示。5.0 XML / 5.4 / 6.0 YAML 中定义的样式如下：

设计上有两个值得注意的点：

• 双 Y 轴：两个字节速率项（fwAcceptBytesIn/Out）被分配到右侧 Y 轴，包速率项在左侧 Y 轴。字节速率数值量级通常远大于包速率（如 Mbps 级 vs pps 级），分开量程可避免图形被某一类曲线压扁；
• 颜色即语义：Accept 系用绿色/蓝色系（00AA00、9999FF、00AAAA），Drop 系用红色/灰色系（CC0000、C8C8C8），Reject 系用深灰/暗红系（666666、960000），Drop 与 Reject 的入站方向用 BOLD_LINE 加粗强调，便于在告警时第一时间识别异常方向。

宏、模板链接与触发器：空白的取舍

README 中明确列出三处空白：

• Macros used：本模板没有定义模板级宏，SNMP 团体字符串完全依赖 Zabbix 内置用户宏{$SNMP_COMMUNITY}在主机级配置；
• Template links：不链接其他模板，可独立使用，也可与 CheckPoint FW-1 模板 同时挂载形成完整监控面（后者负责 CPU/内存/HA，本模板负责接口包过滤）；
• Triggers：模板未内置触发器，即"采集但不告警"。实践中建议用户基于这些监控项自行补充触发器，例如对每个接口计算丢弃率：

(丢弃入站包速率 > 阈值) 且 (接受包速率正常) → 疑似异常流量

Zabbix 5.4 中可写为last(/CheckPoint FW-1 Interfaces/fwDropPcktsIn["{#ADVSNMPVALUE}"],5m) > X之类的表达式（在 5.0 中对应last(host/key,300)语法），并注意{#ADVSNMPVALUE}需通过 LLD 触发器原型（trigger prototype）引用才能对每个接口生效。

验证与排障

部署完成后按以下顺序自检：

1. LLD 是否产出数据：进入「监测 → 发现」查看Interfaces Discovery最近执行状态，正常应每 900 秒成功一次，且最新数据为 JSON；
2. 监控项是否实例化：在最新数据中搜索Interface前缀的监控项，若防火墙有 4 个接口，应看到 4×8=32 个实例化监控项；
3. 数值是否合理：CHANGE_PER_SECOND 处理后，字节项应呈现稳定的速率而非无限增长的累计值；若出现not supported，优先检查团体字符串、MIB 安装位置、以及外部脚本在 ExternalScripts 目录中的可执行权限；
4. MIB 符号解析：SNMP OID 采用CHECKPOINT-MIB::符号名，若 Zabbix Server 上 MIB 缺失，原型会因 OID 无法解析而直接 unsupported。

小结

CheckPoint FW-1 Interfaces是一个"小而专"的 Zabbix 社区模板：它用一条advsnmp.discovery外部发现规则解决 Checkpoint 私有接口表的枚举难题，用 8 个 SNMP 原型 + CHANGE_PER_SECOND 预处理输出接口级 Accept/Drop/Reject 的字节与包速率，再通过双轴图形原型让运维人员一眼看清每块接口的过滤行为。配合 CheckPoint FW-1 模板 使用，即可覆盖一台 Checkpoint 防火墙从系统资源到接口流量过滤的完整可观测面。