ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

Zabbix 监控 D-Link DGS-1100-10/ME revA1 交换机:SNMP 模板解析与部署指南

Zabbix 监控 D-Link DGS-1100-10/ME revA1 交换机:SNMP 模板解析与部署指南

【免费下载链接】community-templates

Zabbix Community Templates repository

项目地址:https://gitcode.com/gh_mirrors/co/community-templates
点击查看免费下载

本文围绕 Zabbix 社区模板仓库中的SNMP D-link DGS-1100-10/ME revA1模板展开,完整讲解该模板的采集架构、10 个设备级监控项、6 个接口 LLD 原型、资产字段自动填充与值映射机制,并结合仓库内 5.0 XML 与 5.4/6.0 YAML 导出文件给出可直接落地的部署与排障方案。读完本文,你将能够把一台开启 SNMP 的 D-Link DGS-1100-10/ME revA1 交换机快速纳入 Zabbix 监控体系,并理解模板每个 key 背后的 OID 与预处理逻辑。

模板概览与适用场景

该模板由 Zabbix 社区维护,位于仓库 Network_Devices/D-Link/template_d-link_dgs-1100-10_me_rev._a1 目录下,其官方定位在 5.0/README.md 的 Overview 中描述得很清楚:

  • 基于 D-Link 官方 MIB(Based on official D-link MIB);
  • 采集通用设备数据(Generic device data);
  • 对网络接口做自动发现(Auto-discovery for Network Interfaces);
  • 自动填充主机资产字段(Fills possible host inventory fields)。

也就是说,这是一份典型的"通用 SNMP 采集 + 接口 LLD"型模板,不依赖 Zabbix agent,适用于无法安装 agent 的网络设备纳管场景。适用对象是 D-Link DGS-1100-10/ME(硬件版本 rev A1)系列交换机,前提是设备已开启 SNMP 服务并配置好可读的 community 字符串(或 SNMPv3 凭据)。

模板在仓库中提供三个 Zabbix 版本对应的导出文件,内容完全一致,只是导出格式与版本号不同:

Zabbix 版本文件说明
5.0template_d-link_dgs-1100-10_me_rev._a1.xmlXML 导出格式
5.4template_d-link_dgs-1100-10_me_rev._a1.yamlYAML 导出格式
6.0template_d-link_dgs-1100-10_me_rev._a1.yamlYAML 导出格式

有一点细节值得注意:导出文件里的内部模板名(template字段)为SNMP D-link DGS-1100-10ME revA1,而对外显示名(name字段)为SNMP D-link DGS-1100-10/ME revA1,导入后在模板列表中看到的是带斜杠的显示名。模板被归入Templates与ZBX-DLINK-TEMPLATES两个模板组,并划分了General(设备通用)与Interface(s)(接口)两个应用(application)来组织监控项。

模板导入与主机接入步骤

按仓库根 README.md 中描述的社区模板使用流程,接入该模板只需三步:

  1. 下载并导入模板:在 Zabbix Web 前端进入数据采集 → 模板,点击右上角导入,选择对应 Zabbix 版本的 XML/YAML 文件(5.0 用 XML,5.4/6.0 用 YAML),导入时按需勾选"更新现有模板""创建新的模板组"等覆盖策略。
  2. 按配置要求设置模板/主机:该模板自身不依赖任何宏、模板链接或外部脚本,因此导入后即可直接使用,无需额外填宏。
  3. 将模板链接到主机:在主机配置中新增一个SNMP 接口(填设备 IP、端口 161、SNMP 版本与 community/安全名),并在"模板"标签页链接本模板。

建议在链接前先确认设备侧的 SNMP 可达性,例如用snmpwalk -v2c -c <community> <设备IP> .1.3.6.1.4.1.171.10.134.2.1.1能正常返回数据,再接入 Zabbix,可避免大量 "No Such Object" 的无效轮询。

采集架构总览:两类监控对象

从 5.0 XML 导出(6.0 YAML 与之等价)可以看出,模板的采集面分为两层:

  • 设备级固定监控项(10 个):全部挂在General应用下,轮询固定 OID,覆盖设备身份、版本、序列号、CPU/内存利用率、运行时长等;
  • 接口级原型监控项(6 个):由一条名为Network Interfaces的发现规则(LLD)驱动,挂在Interface(s)应用下,对每个被发现的接口自动生成监控项。

OID 来源也分两类:一类是标准 MIB——SNMPv2-MIB的system组(.1.3.6.1.2.1.1.*)与IF-MIB的ifTable(.1.3.6.1.2.1.2.2.1.*);另一类是 D-Link 私有 MIB——企业号171(.1.3.6.1.4.1.171.*)下的设备信息对象。这正呼应了 README 中"基于官方 D-Link MIB"的表述:标准部分保证通用性,私有部分提供 D-Link 特有的 CPU/内存统计。

设备级监控项详解(10 项)

README 的 "Items collected" 表格罗列了全部 10 个设备级监控项,结合 XML/YAML 中补充的 OID、单位、保留策略与资产链接,汇总如下:

监控项名称KeyOID更新间隔类型/单位历史/趋势资产链接
Device CPU utilizationcpuLast5MinUsage.1.3.6.1.4.1.171.10.134.2.1.1.30.3.060s数值 /%7d / 30d—
Device memory utilizationramLast5MinUsage.1.3.6.1.4.1.171.10.134.2.1.1.31.3.060s数值 /%7d / 30d—
Device uptimesysUpTime.1.3.6.1.2.1.1.3.0300s数值 /uptime30d / 0—
Device namesysName.1.3.6.1.2.1.1.5.03600s字符1d / 0ALIAS
Device contact detailssysContact.1.3.6.1.2.1.1.4.03600s字符1d / 0CONTACT
Device descriptionsysDeviceType.1.3.6.1.4.1.171.10.134.2.1.1.1.4.03600s字符1d / 0MODEL
Device firmware versionsysFirmwareVersion.1.3.6.1.4.1.171.10.134.2.1.1.1.3.03600s字符1d / 0SOFTWARE
Device hardware versionsysHardwareVersion.1.3.6.1.4.1.171.10.134.2.1.1.1.2.03600s字符1d / 0HARDWARE
Device serial numbersysSerialNumber.1.3.6.1.4.1.171.10.134.2.1.1.29.03600s字符1d / 0SERIALNO_A
Device locationsysLocationName.1.3.6.1.4.1.171.10.134.2.1.1.3.03600s字符1d / 0LOCATION

几个值得注意的设计点:

  • 轮询频率分层:CPU/内存是动态指标,每 60 秒采集一次并保留 7 天历史 + 30 天趋势;sysUpTime每 300 秒一次并保留 30 天历史;而设备名称、序列号、版本号等静态信息每小时(3600s)采一次即可,且不保留趋势(trends: 0),避免无意义的存储开销。
  • 私有 OID 的结构暗示:从 OID 分支看,.1.3.6.1.4.1.171.10.134.2.1.1下的.1.2/.1.3/.1.4分别是硬件版本、固件版本、设备类型描述,.29是序列号,.30.3与.31.3是"最近 5 分钟平均"的 CPU/内存利用率。README 中对应的英文描述也明确指出这两项表示average CPU/RAM usage in last 5 minute of the switch in percentage,说明它们并非瞬时值,做告警阈值时需要结合这一语义。
  • 字符型监控项:所有身份类信息均声明为value_type: CHAR,在 Zabbix 中以字符串存储,适合直接写入资产或用于展示,不参与数值计算。

sysUpTime 的预处理:TimeTicks 到可读时长

sysUpTime是 SNMP 标准对象(SNMPv2-MIB的system组第 3 个叶子),返回的是 TimeTicks 类型——以百分之一秒为单位的计时器。模板在 6.0 YAML 中为它配置了预处理步骤:

preprocessing: - type: MULTIPLIER parameters: - '0.01'

即把原始 TimeTicks 值乘以 0.01 换算为秒,再配合监控项的units: uptime单位,Zabbix 前端即可把数值渲染为"x 天 x 小时 x 分"的可读时长。这一步在 XML 导出中同样存在(<type>MULTIPLIER</type><params>0.01</params>),两个版本行为一致。若直接使用原始值而不做换算,数据会放大 100 倍且语义错误——这是导入第三方模板后最常踩的坑之一。

资产字段自动填充(Inventory)

README 明确提到模板会 "Fills possible host inventory fields",这是本模板的一大特色:7 个设备信息监控项通过inventory_link属性把采集到的值同步到主机资产(Inventory)字段,实现"设备身份档案自动维护":

监控项资产字段(inventory_link)
Device name (sysName)ALIAS
Device contact details (sysContact)CONTACT
Device description (sysDeviceType)MODEL
Device firmware version (sysFirmwareVersion)SOFTWARE
Device hardware version (sysHardwareVersion)HARDWARE
Device serial number (sysSerialNumber)SERIALNO_A
Device location (sysLocationName)LOCATION

实际效果是:只要监控项能读到值,主机资产页的别名、联系人、型号、软硬件版本、序列号、位置就会被自动填写并随轮询刷新,省去人工录入资产信息的步骤。这也解释了为什么这些静态项的轮询间隔放宽到 3600 秒——资产字段并不需要秒级新鲜度。

网络接口自动发现(LLD)

README 的 "Discovery rules" 部分列出了模板唯一一条发现规则:Network Interfaces,类型为SNMP agent,key 为ifIndex,更新间隔 3600 秒。导出文件给出了完整实现:

snmp_oid: discovery[{#SNMPVALUE},.1.3.6.1.2.1.2.2.1.1] key: ifIndex delay: 3600 lifetime: 1d

discovery[{#SNMPVALUE},<OID>]是 Zabbix 的 SNMP 自动发现语法:轮询IF-MIB的ifTable第一列ifIndex(.1.3.6.1.2.1.2.2.1.1),把表中每个索引值作为宏{#SNMPVALUE}输出,同时生成配套的{#SNMPINDEX}宏(用于拼接各列 OID 的实例编号)。lifetime: 1d表示某个接口从 MIB 表中消失后,其派生监控项会保留 1 天再被清理,避免拔线换口时数据瞬间丢失。

通过这一条规则,模板可以自动感知交换机上存在的全部物理/逻辑接口(包括 SFP 光口、级联口等),无需人工逐个添加监控项。

接口原型监控项详解(6 个)

发现规则下挂了 6 个 item prototype(在 README 的 "Items collected" 中标注LLD的条目),每个原型都以{#SNMPVALUE}为后缀生成独立监控项:

原型名称Key 模板OID 模板更新间隔单位预处理
Incoming traffic on interface $1ifInOctets[{#SNMPVALUE}].1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}300sbpsCHANGE_PER_SECOND → MULTIPLIER 8
Outgoing traffic on interface $1ifOutOctets[{#SNMPVALUE}].1.3.6.1.2.1.2.2.1.16.{#SNMPINDEX}300sbpsCHANGE_PER_SECOND → MULTIPLIER 8
Inbound errors on interface $1ifInErrors[{#SNMPVALUE}].1.3.6.1.2.1.2.2.1.14.{#SNMPINDEX}3600s—SIMPLE_CHANGE
Operational status of interface $1ifOperStatus[{#SNMPVALUE}].1.3.6.1.2.1.2.2.1.8.{#SNMPINDEX}300s—值映射 ifOperStatus
Speed of interface $1ifSpeed[{#SNMPVALUE}].1.3.6.1.2.1.2.2.1.5.{#SNMPINDEX}3600sbps—
Uptime of interface $1ifLastChange[{#SNMPVALUE}].1.3.6.1.2.1.2.2.1.9.{#SNMPINDEX}3600suptime—

其数据链路可以拆解如下:

  • 流量换算(关键):ifInOctets/ifOutOctets是累计计数器(octets,含帧头),原始值单调递增。模板先做CHANGE_PER_SECOND(差值除以轮询间隔,得到每秒字节数),再做MULTIPLIER 8(字节转比特),最终单位设为bps。这样 Zabbix 前端看到的即是标准的"每秒进出流量(bps)"曲线,可直接用于带宽监控与告警。历史保留策略上,两个流量项的趋势保留 180 天,适合做长期容量分析。
  • 错误计数:ifInErrors同样是累计计数器,模板用SIMPLE_CHANGE(简单差值)把它转成"两次轮询之间的新增错误数",用于观察接口丢包/CRC 错误趋势;轮询间隔放宽到 3600 秒,属于低频健康检查。
  • 接口状态:ifOperStatus返回 1~7 的整数状态码,模板为它挂了值映射(见下节),使最新值显示为可读的up/down/testing等状态词。
  • 速率与在线时长:ifSpeed返回接口当前带宽估计值(bps),ifLastChange返回接口进入当前状态的时间点(TimeTicks,单位声明为uptime)。

ifOperStatus 值映射

模板在导出文件中附带了一个名为SNMP interface status (ifOperStatus)的值映射(value map),把 RFC 2863ifOperStatus的 7 个枚举值映射为可读文本:

原始值映射文本含义
1up接口正常转发
2down接口关闭
3testing测试模式,不转发业务报文
4unknown状态未知
5dormant等待外部动作激活
6notPresent硬件未安装/未识别
7lowerLayerDown下层链路故障导致不可用

该值映射同时存在于 5.0 XML 与 5.4/6.0 YAML 中,且 5.4 之后带 UUID(de9a9ec0ee304880867e719c05adbba0)。映射后,接口状态监控项的最新值、最新值趋势与后续任何基于它编写的触发器表达式都会显示为这些可读状态,是排查"端口 down 但为什么 down"的第一手依据。

图形原型:接口出入流量

模板还定义了一条 graph prototype,自动为每个发现的接口生成一张进出流量对比图。图形名称使用表达式动态生成:

interface {{HOSTNAME}:ifAlias[{#SNMPVALUE}].last(0)}

图形包含两条曲线:ifInOctets[{#SNMPVALUE}](绿色00C800)与ifOutOctets[{#SNMPVALUE}](蓝色3333FF)。这里有一个值得注意的实现细节:图形标题表达式引用了ifAlias[{#SNMPVALUE}]这个监控项,但它并未在本模板的 item prototype 中定义。因此图形标题的实际呈现效果,取决于该主机上是否已存在同名监控项(例如由其他模板或手工创建);若不存在,表达式会在图形命名时退化为空值或解析失败。读者导入后可在"最新数据 → 图形"中实际核对该模板生成的图形标题,按需决定是否为ifAlias补充采集。

宏、模板链接与触发器的设计取舍

README 的三处声明值得原样继承:

  • Macros used:无(There are no macros links in this template);
  • Template links:无(There are no template links in this template);
  • Triggers:无(There are no triggers in this template)。

这是一个刻意的"采集型模板"设计:模板只负责把数据稳定地采进来,把告警策略的裁量权留给使用方。由于没有触发器,模板不会在接口 down、CPU 飙高时自动告警。如果你需要告警,可以基于本模板的监控项自行补充,例如:

  • 接口状态告警:last(/<主机>/ifOperStatus[{#SNMPVALUE}])<>1(值为 1 即up),并结合 LLD 宏按接口定制;
  • CPU/内存利用率告警:对cpuLast5MinUsage、ramLast5MinUsage设置阈值表达式(注意二者语义是"最近 5 分钟平均");
  • 接口错误增长告警:基于ifInErrors[{#SNMPVALUE}]的SIMPLE_CHANGE差值设定阈值。

此类触发器可在"主机 → 模板"之外按需手动添加到主机或克隆模板中,不影响原模板的通用性。若希望沿用社区惯例,也可参考仓库 README.md 中关于模板使用与协作的说明,在 Zabbix 官方模板规范框架下扩展。

部署注意事项与排障要点

  • SNMP 版本与凭据:模板监控项类型均为SNMP agent,不绑定特定 SNMP 版本;设备侧需开启 SNMP 并保证 Zabbix 主机到设备的 161/UDP 可达。社区字符串或 SNMPv3 凭据在主机级配置,模板内无相关宏。
  • OID 可用性验证:模板依赖 D-Link 私有 MIB 的 CPU/内存对象(.1.3.6.1.4.1.171.10.134.2.1.1.30.3.0与.31.3.0)以及标准ifTable。若设备固件较老或型号变体不同,私有 OID 可能无响应,表现为 CPU/内存监控项显示 "No Such Object"。建议导入前先用snmpwalk抽查上述 OID 是否返回数据。
  • 轮询节奏与资源占用:模板整体轮询量很小——设备级仅 2 个 60s 高频项 + 若干 300s/3600s 低频项;接口级每个接口 2 个 300s 流量项 + 4 个 3600s 低频项,对小型 DGS-1100 系列(10 口设备)而言负载可忽略。
  • 多版本文件一致性:5.0 XML 与 5.4/6.0 YAML 在监控项、原型、值映射、图形原型上完全一致,仅导出格式与 UUID 标注不同,可按部署的 Zabbix 主版本任选其一导入。

与其他 D-Link 模板的关系

在仓库 Network_Devices/D-Link 目录下,除了本模板,社区还维护了template_d-link_dgs_1100(DGS 1100 系列通用版)、template_d-link_dgs-1100-08v2_snmpv2、template_d-link_dgs-1210-52_rev._b/_c、template_d-link_dgs-3120-xx等多个 D-Link 交换机模板。本模板的特点是"轻量、通用、面向 rev A1 硬件",聚焦设备身份、资源利用率与接口自动发现;若你纳管的是 DGS-1100 系列其他硬件版本或需要更细粒度的接口统计,可在该目录下横向对比选择,必要时叠加使用。但需要明确:本模板自身不链接任何其他模板,全部能力自包含。

综上,SNMP D-link DGS-1100-10/ME revA1是一份结构清晰、零外部依赖的 SNMP 采集模板:10 个设备级监控项覆盖身份与资源指标,1 条 LLD 规则加 6 个接口原型完成接口自动化纳管,7 个资产链接实现资产档案自动维护,配合 ifOperStatus 值映射与接口流量图形原型,即可在 Zabbix 5.0/5.4/6.0 中快速构建起对 D-Link DGS-1100-10/ME 交换机的完整可见性。部署时按上文核对 SNMP 可达性与私有 OID 可用性,再按需补充触发器,即可投入生产使用。

【免费下载链接】community-templates

Zabbix Community Templates repository

项目地址:https://gitcode.com/gh_mirrors/co/community-templates
点击查看免费下载
上一篇:AutoRemesher在工业设计中的应用:产品模型的拓扑优化实践
下一篇:Apache Cassandra入门教程:1小时快速上手分布式数据库

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进