华为 VRP SNMP 模板（Walk + 依赖项）

版本: 7.4-walk-1 | 适用: Zabbix 7.4.x | 厂商: FlyingRome

1. 背景：Zabbix 服务器为什么老是挂（10.160.10.213）

环境：Zabbix 7.4.2 + MySQL 8.0.43 + AlmaLinux 9.6 + Docker Compose。
根因一（容量）：SNMP poller 默认只有 1 个进程。
根因二（放大器）：旧版华为模板对每台交换机逐个 OID 发 GetRequest（每台约 1962 个接口项 + 传感器项）。下联 down 端口的 OID 每次要 3~5 秒超时，仍每分钟重试。全网数万个 SNMP 项 / 60s ≈ 1000+ 请求/秒，单 poller 100% 打满 → 采集队列积压 2~9 分钟、约 1.5 万项 “became not supported: timed out”、数据延迟与误告警，最终 server 频繁假死。

结论: 不是设备单点问题，而是 poll 并发不足 × 逐 OID 轮询放大 的结构性问题。

1) 运维层：将 SNMP poller 由 1 提升到 30 并重启（ZBX_STARTSNMPPOLLERS=30）。

验证：snmp poller 忙碌由 100% → ~9.5%，unreachable poller 由 42% → 0%。 2) 模板层：本模板用 “一次 bulk walk + 依赖项（dependent items）” 彻底替代逐 OID 轮询。

net.if.walk：单条 master 项，一次 SNMP walk[]（GetBulk）取回接口多列 OID： ifOperStatus, ifAdminStatus, ifDescr, ifName, ifAlias, ifHighSpeed, ifType, ifHCInOctets, ifHCOutOctets, 各类 errors / discards。
net.if.discovery：DEPENDENT 发现规则，预处理 SNMP_WALK_TO_JSON 把 walk 结果转 JSON，产出 {#SNMPINDEX} 等宏。
9 类依赖项原型（每类 218 项/主机）：status / type / speed / in / out / in.errors / out.errors / in.discards / out.discards。每个依赖项用预处理 SNMP_WALK_VALUE: <OID>.{#SNMPINDEX} 从 master 取值，master_item = net.if.walk。
传感器沿用 SNMP_AGENT（风扇、温度、CPU、内存、型号、序列号、版本等）。
效果：每台主机每轮 SNMP 请求由 ~1962 次 → 1 次 bulk walk，SNMP 负载降低约 99%。

导入模板（createMissing: true）。
重要（迁移坑）：若主机已用旧模板且 item key 相同，Zabbix 会保留旧的逐 OID 项（类型/预处理可能不更新）。建议：先 unlink 旧模板 → 删除旧 net.if.* 逐 OID 项 → 再链接本模板，让 LLD 重新生成“依赖项”；若已链接，删除旧项后执行一次 config_cache_reload 即可由 LLD 重建。
主机需配置 SNMP 接口（示例 SNMPv3：authPriv / SHA / AES）。
大核心建议把 net.if.walk 的 timeout 调大（如 30s） 以容忍慢速 bulk。

绝对不要在两个 Zabbix 主机上填写同一台设备的 IP，否则 SNMPv3 会报 SNMP engineId is not unique，导致该设备相关所有项采集失败（本模板排障中即遇到）。
主 net.if.walk 的 value_type = TEXT，history 必须为 0（历史由依赖项承载）；设为非 0 会导致主项不被调度。
若设备不支持 EtherLike-MIB（duplex），本模板不含 duplex 项（本核心即不支持）。