导读

本文以 Zabbix 社区模板仓库（community-templates）中 Juniper SRX 系列模板 为核心，系统讲解如何通过 SNMP 对 Juniper SRX 系列防火墙进行全维度监控。读者将掌握该模板的导入方法、19 个核心监控项与 6 类接口自动发现项的作用原理、全部触发器告警阈值与处理建议，以及基于 5.4 版 YAML 导出文件 的源码级配置细节，可直接落地到生产环境。

模板概览：监控什么、面向谁

Template Juniper SRX是 Zabbix 社区为Juniper SRX 系列防火墙编写的开箱即用监控模板，全部数据通过SNMP agent采集，无需在被监控设备上安装任何 Agent 或额外组件。从模板定义（5.4 版 YAML）可以看到，模板归属于两个主机组：Networking Hardware与Templates，导出格式版本为5.4，导出日期为2021-11-25。

该模板覆盖的监控维度包括：

• 设备可用性：ICMP Ping 存活探测；
• 会话（Flow Session）容量：当前会话数、最大会话数、可用会话百分比；
• 双节点资源使用率：RE（Routing Engine，路由引擎）与 PFE（Packet Forwarding Engine，包转发引擎）的 CPU、内存使用率；
• 硬件健康：RE 节点 CPU 温度、红色/黄色告警灯状态；
• 系统运行状态：Uptime（重启检测）；
• 接口流量：通过 LLD 自动发现 fe/ge/xe/ae/reth/st/vcp/vlan 等接口，采集出入向流量、错误、丢弃包。

仓库同时提供了三个 Zabbix 版本对应的模板文件：

三个版本的内容保持一致（5.0 版为 XML 导出，5.4/6.0 版为 YAML 导出），请按你的 Zabbix Server 版本选择对应文件导入。

关于宏与模板链接

按官方 README（5.4/README.md）的说明，该模板不依赖任何用户宏（Macros），也没有模板链接（Template links），即它是一个完全自洽、零配置依赖的独立模板——导入后只需要在主机上配置好 SNMP 接口即可工作。对不熟悉 Zabbix 模板机制的读者而言，这意味着上手门槛非常低：无需预先定义宏、无需链接其他模板。

部署指南：导入模板并关联主机

参照仓库根目录 README.md 中给出的通用使用流程，Juniper SRX 模板的落地步骤如下：

1. 导入模板：登录 Zabbix Web 界面，进入Data collection → Templates，点击右上角Import，选择对应版本目录下的模板文件（XML 或 YAML）上传导入；
2. 配置 SNMP：确保 Juniper SRX 设备已开启 SNMP（在 Junos 中使用set snmp community public之类的配置启用，模板默认使用 SNMPv1/v2c 的 community 方式读取，未使用 SNMPv3）；
3. 关联主机：在主机配置中填写 SRX 设备的 IP/DNS，添加 SNMP 接口（端口默认 161），并在Templates标签页链接Juniper SRX模板；
4. 验证数据：等待一个采集周期后，在Latest data中确认jnxJsSPUMonitoringCPUUsage.0、jnxOperatingTemp.9.1.0.0等监控项开始出现数据。

注意：该模板的所有监控项均通过 Zabbix Server 主动轮询 SNMP 获取，不需要在防火墙上安装 Zabbix Agent，因此适用于所有支持 SNMP 的 Juniper SRX 系列设备（包括 SRX 分支防火墙与 SRX 系列服务网关）。

核心监控项详解：读懂 19 个 Items

模板共定义了 19 个监控项（其中 1 个为计算型、1 个为简单检查、其余为 SNMP agent 采集），下面按功能域分组逐项说明。监控项在 YAML 中通过items段定义，并统一使用tags标记了Application: Device Health（设备健康）、Application: Performance（性能）或Application: Interfaces（接口）三类标签，便于在 Zabbix 中按标签筛选与聚合。

设备可用性与存活检测

Ping check是唯一的非 SNMP 监控项，通过 Zabbix Server 直接发起 ICMP 探测来判断防火墙是否在线。它挂载了值映射（valuemap）Service state——在 YAML 的 valuemaps 段 中，数值0被映射为Down、1映射为Up，使监控界面展示更直观。

防火墙会话容量（Flow Sessions）

SRX 作为状态化防火墙，其并发会话数直接决定设备承载能力，模板用三个监控项 + 一个计算项完整覆盖了会话水位：

其中Flow sessions (Available)是模板中唯一的计算型监控项（CALCULATED），其计算表达式（见 YAML 第 43-48 行）为：

((last(//jnxJsSPUMonitoringMaxFlowSession.0)-last(//jnxJsSPUMonitoringCurrentFlowSession.0))/last(//jnxJsSPUMonitoringMaxFlowSession.0))*100

即可用会话百分比 =（最大会话数 − 当前会话数）÷ 最大会话数 × 100%。该计算项不直接采集 SNMP，而是复用 Max 与 Current 两个原始监控项的最近值进行运算，从而得到"还剩多少会话余量"这一关键运维指标。当可用会话不足时，新连接将无法建立，因此它是判断设备是否逼近会话瓶颈的核心依据。

RE 与 PFE 资源使用率（CPU / 内存）

SRX 的双节点架构（Node 0 / Node 1，常见于双路由引擎或集群部署）体现在监控项的命名与 OID 后缀上。模板分别采集RE（路由引擎）与PFE（包转发引擎）的 CPU 与内存使用率，覆盖两类不同的 OID 家族：

PFE 相关（jnxJsSPUMonitoring 家族，企业 OID 前缀 1.3.6.1.4.1.2636.3.39.1.12.1.1.1）：

RE 相关（jnxOperating 家族，企业 OID 前缀 1.3.6.1.4.1.2636.3.1.13.1）：

从 OID 结构可以推断：RE 相关 OID 末尾的9.1.0.0/9.2.0.0分别对应 Node 0（.9.1.）与 Node 1（.9.2.），9通常对应 RE 组件的索引编号。四个监控项的单位均为%，采集周期 30 秒，属于高频采样的性能类监控项。RE 负责控制平面（路由协议、管理面），PFE 负责数据平面（报文转发），二者的 CPU/内存水位含义不同——RE 满载影响设备自管理能力，PFE 满载则直接影响转发性能与新建会话能力，后续触发器的告警描述也正是围绕这两个维度设计的。

硬件健康：温度与告警灯

CPU 温度监控项复用jnxOperatingTemp家族（1.3.6.1.4.1.2636.3.1.13.1.7），同样区分 Node 0 / Node 1。红/黄告警灯对应 Juniper 设备的机箱告警体系：红色告警（jnxRedAlarmState）代表严重故障（如硬件损坏、温度超限），黄色告警（jnxYellowAlarmState）代表需要注意的非致命问题（如冗余组件降级）。模板为二者分别配置了告警触发器（详见后文），并将它们归类到Device Health标签下。

系统运行时间与重启检测

Uptime使用标准 SNMP MIB-II 的sysUpTimeOID（1.3.6.1.2.1.1.3.0），其原始单位为百分之一秒（centiseconds），因此模板为它配置了MULTIPLIER 预处理（YAML 第 384-388 行），将返回值乘以0.01转换为以秒为单位的运行时长。配合Uptime < 600的触发器，可在设备重启后 10 分钟内自动感知（详见触发器章节）。

发现规则：JunOS 接口自动发现（LLD）

模板通过一条名为JunOS Interfaces的 SNMP 发现规则（YAML 第 399-412 行）实现接口的自动发现与批量监控：

• 发现方式：SNMP agent 轮询ifDescr（OID1.3.6.1.2.1.2.2.1.2），发现规则 key 为discovery.ifDescr，更新周期 300 秒（5 分钟），即每 5 分钟扫描一次接口列表；
• 宏注入：发现规则使用discovery[{#SNMPVALUE},1.3.6.1.2.1.2.2.1.2]语法，将接口描述写入{#SNMPVALUE}宏（接口名），同时 Zabbix 自动生成{#SNMPINDEX}宏（接口索引），供后续原型拼接 OID；
• 过滤正则：并非所有接口都会被监控，模板在filter段通过正则对{#SNMPVALUE}进行白名单过滤：

^(fe|ge|xe)-[0-9]+\/[0-9]+\/[0-9]+\.[0-9]+$|^(fe|ge|xe)-[0-9]+\/[0-9]+\/[0-9]+$|^(ae|reth|st)[0-9]+\.[0-9]+$|^(ae|reth|st)[0-9]$|^vcp-[0-9]+$|^vlan.[0-9]+$

该正则依次匹配 Juniper SRX 常见的接口命名规范：

从该正则可以看到模板作者的工程考量：主动排除了lo0（loopback）、irb、fxp等非业务接口，也避免了对xe-0/0/0这类不带子接口编号的重复匹配歧义，确保发现的接口全部是值得监控的数据面/管理面接口。

接口监控项原型（Item Prototypes）

发现规则下定义了6 个接口监控项原型，全部基于 IF-MIB（1.3.6.1.2.1.2.2.1）计数器采集，采集周期 60 秒：

这里有两个值得注意的实现细节：

1. CHANGE_PER_SECOND 预处理：IF-MIB 的 octets/discards/errors 都是单调递增的计数器，直接展示没有意义。模板对全部 6 个原型都配置了CHANGE_PER_SECOND预处理（YAML 第 422-426 行），将两次采集间的差值换算成"每秒增量"，即速率值；
2. MULTIPLIER 8 换算流量：入/出向流量两个原型在速率换算之后，再叠加MULTIPLIER 8预处理（YAML 第 441-449 行），把字节每秒（B/s）乘以 8 转换为比特每秒（bps），与网络运维习惯一致；这两个原型的值类型（value_type）设为FLOAT、单位设为bps。

此外，每个接口原型默认保存 7 天历史数据（history: 7d），并以Application: Interfaces标签归类。

图形原型（Graph Prototypes）

发现规则还附带一个名为Interface {#SNMPVALUE}的图形原型（YAML 第 528-575 行），将上述 6 个接口指标以不同绘制方式组合到一张图上：

• 入向流量：FILLED_REGION填充区域图，颜色2618B1；
• 出向流量：BOLD_LINE粗线，颜色FFC600；
• 入向丢弃、入向错误、出向丢弃、出向错误：细线，颜色分别为594CD8、7B72D8、FFD440、FFE073。

全部 6 个图形项均绘制在右侧 Y 轴（yaxisside: RIGHT）。每发现一个接口，Zabbix 就会自动为该接口生成一张综合流量/错误/丢弃视图，无需手工建图。

触发器与告警体系：阈值、表达式与处置建议

虽然 5.4 版 README.md 中"Triggers"一节标注为There are no triggers in this template，但实际导出的 YAML 模板文件 中完整定义了 15 个触发器（5.0 版 XML 亦然）。这是 README 与模板导出内容不一致的一个典型情况，实际告警能力以模板文件为准。以下按告警场景分组说明。

可用性告警（灾难级）

sum(/Juniper SRX/icmpping,#3)=0 or ({TRIGGER.VALUE}=1 and sum(/Juniper SRX/icmpping,#3)<>3)

• 名称：Ping check，优先级DISASTER（灾难）；
• 逻辑解读：最近 3 次探测全部失败（sum=0），或此前已处于告警态（{TRIGGER.VALUE}=1）且最近 3 次并非全部成功（<>3）；
• 告警描述：The firewall device has stopped responding. This could indicate a failure and needs to be investigated.（防火墙已停止响应，可能故障，需立即排查）。

会话容量告警（Warning / High）

计算项Flow sessions (Available)的可用会话百分比触发两级告警：

两条触发器的描述给出了相同的处置建议（Actions）：

• 审查流量模式（Review traffic patterns）；
• 查找高非活跃超时会话（Look for sessions with high inactivity timeouts）；
• 评估设备型号是否满足容量需求（Review Device type）。

性能资源告警（Average）

模板为 RE/PFE 的 CPU、内存分别配置了阈值 95% 的告警，均为AVERAGE（平均）优先级，并区分 Node 0 / Node 1：

注意这里使用的是min(...,60s)>95语义——即"最近 60 秒内的最小值都超过 95%"，比单纯看最新值更稳健，能过滤瞬时毛刺，只有持续高负载才触发。各触发器的处置建议（Actions）随资源类型不同而不同：

• PFE CPU >95%：审查流量模式、PPS（每秒包数）、会话数——转发面满载将影响转发响应与新建会话（"Device responsiveness for transit traffic is likely to be impacted including session buildup"）；
• PFE 内存 >95%：检查系统日志、清理未使用功能配置、禁用不需要的 ALG（应用层网关）——转发操作可能因无法分配内存而受影响；
• RE CPU >95%：禁用 traceoptions 调试跟踪、清理存储、核查系统进程——设备自身流量的响应能力将受影响；
• RE 内存 >95%：核查路由表规模、核查运行中的系统进程、检查系统日志——设备将开始主动内存清理（"Device will begin active memory clean up attempts"）。

硬件健康告警

温度触发器在 60 秒窗口内最小值超过65°C时告警。红/黄告警触发器表达式为last(...)<>2，即告警状态值不等于 2即触发——可以推断 Juniper 的 alarm 状态 MIB 中数值2通常代表"无告警/正常"（1代表存在告警），因此只要设备上报了非 2 的告警状态，Zabbix 就会告警；红色告警优先级为 HIGH，黄色为 AVERAGE，与故障严重程度对应。

重启检测

last(/Juniper SRX/Uptime)<600

• 名称：{HOSTNAME} Has just been restarted，优先级 AVERAGE；
• 含义：设备运行时间（经 0.01 乘数换算后的秒数）小于 600 秒（10 分钟），判定设备刚刚重启，便于运维在设备异常重启后第一时间收到通知。

值映射与标签体系

模板末尾定义了名为Service state的值映射（YAML 第 576-584 行）：

该映射仅应用于Ping check监控项。所有监控项均带Application标签，共三个取值：Device Health（Ping、温度、红黄告警、Uptime）、Performance（会话、RE/PFE CPU/内存）、Interfaces（LLD 接口原型），可在 Zabbix 标签筛选中按应用域快速过滤。

运维实践建议

基于对模板源码的解析，以下是在实际部署中的关键建议：

1. 选择正确的版本文件：Zabbix 5.0 用 5.0 目录下的 XML，5.4 与 6.0 分别使用对应 YAML；高版本 Zabbix 也可导入低版本文件并自动升级；
2. SNMP 前置条件：模板基于 SNMPv1/v2c community 采集，需在 Junos 中配置 SNMP community 与允许访问的 Zabbix Server 地址（set snmp community <name> clients <zabbix-ip>），并确保管理面可达；
3. 双节点适配：监控项同时覆盖 Node 0 / Node 1，适用于双 RE 或集群场景；单节点设备上 Node 1 相关 OID 可能无数据，可通过禁用对应监控项或接受无数据状态处理；
4. 接口发现范围：发现过滤正则已覆盖物理接口、子接口、AE/reth 聚合接口、VCP 与 VLAN 接口，若你的设备使用xe-以外命名（如et-高速接口），可参考该正则结构自行扩充白名单；
5. 阈值调优：95% 的 CPU/内存阈值与 65°C 温度阈值适用于多数场景，生产环境可根据设备型号手册与历史基线调整；会话容量告警的 10%/20% 两级阈值已内置处置建议，适合作为会话风暴的第一道防线；
6. Uptime 单位注意：sysUpTime原始单位为百分之一秒，模板已通过MULTIPLIER 0.01预处理修正为秒，若你在外部工具中直接读取该 OID，需自行换算。

同仓库其他 Juniper 模板的定位

community-templates 的Network_Devices/Juniper目录下还提供了面向其他 Juniper 产品线的模板，便于按设备类型选型：

• template_juniper_ex_series：面向EX 系列交换机，监控维度与 SRX 模板类似（Ping、红黄告警、负载、CPU/内存、RE 温度、接口 LLD），同样支持虚拟机箱（virtual chassis）场景；
• template_juniper_bgp_stats_by_snmp 与 template_juniper_total：分别面向 BGP 会话统计与 Juniper 设备综合指标。

SRX 模板的独特价值在于其Flow Session（会话容量）监控——这是防火墙区别于交换机/路由器的核心指标，模板通过 Max/Current 两个 SNMP 项加一个计算项完整覆盖了会话水位告警，是防火墙容量规划与故障排查的有力工具。

附录：关键 OID 速查表