导读

本文围绕 Zabbix Community Templates 仓库中的Mikrotik Script Execution模板（位于Network_Devices/Mikrotik/template_mikrotik_script_execution_via_snmp/），完整讲解其基于 SNMP 的 LLD（Low-Level Discovery）设计思路：模板会自动发现 RouterOS 路由器上名称以Get开头的自定义脚本，将其动态注册为监控项并周期性采集执行结果，进而可用于绘图、配置触发器与告警。读完本文，你将掌握该模板的 OID 语义、发现规则与采集项的完整配置逻辑、过滤器定制方法，以及 RouterOS 侧的脚本准备与 Zabbix 侧的导入验证流程。

一、模板定位与设计动机

RouterOS（MikroTik 路由器操作系统）内置/system script脚本引擎，运维人员常通过脚本输出路由器状态、接口计数或自定义业务指标。常规 Zabbix 监控模板只能采集预定义 OID，无法覆盖用户自定义的脚本指标。

Mikrotik Script Execution模板正是为解决这一问题而设计：它通过 RouterOS 的 MIKROTIK-MIB 脚本表，自动发现路由器上已创建的、名称以Get开头的脚本，并把每个脚本的执行结果映射为一个独立监控项。官方 README 的描述是：

This template will discover any scripts created in the router which names starts with "Get" (can be customized in the template discovery filter) and will make them available as an item to be plotted in graphics or create triggers and alarms.

即：脚本名称前缀Get可以在模板的发现过滤器（discovery filter）中自定义；发现到的脚本会以监控项形式呈现，可用于绘图，或作为触发器与告警的数据源。模板作者为 Antonio Forster。

模板在仓库中的版本结构

该模板按 Zabbix 版本分目录存放，仓库中提供三份导出文件，内容语义一致、仅导出格式不同：

以 6.0 版为例，导出的 YAML 元信息表明该模板位于Templates组、模板名为Mikrotik Script Execution，创建于2021-11-21。其结构非常精简：仅包含 1 条发现规则（Discovery rule）和 1 个监控项原型（Item prototype），不包含宏、模板链接和触发器——这正是其"轻量、可扩展"的定位：把脚本发现与采集做扎实，告警逻辑交由使用者按需补充。

二、工作原理：脚本表与执行 OID

整个模板的核心是 MikroTik 私有 MIB 根 OID1.3.6.1.4.1.14988。仓库中其他 MikroTik 模板（如 template_mikrotik_os/7.4/template_mikrotik_os.yaml）同样以该根 OID 访问 RouterOS 的无线、系统等信息，印证了14988是访问 RouterOS 私有 MIB 的固定入口。

在本模板中，从 YAML 配置可见两条关键 OID 链路（以 6.0 版 template_mikrotik_script_execution_via_snmp.yaml 为准）：

• 发现阶段：1.3.6.1.4.1.14988.1.1.8—— 依据 RouterOS 的 MIKROTIK-MIB 语义，该子树对应系统脚本名称表，可以枚举路由器上已存在的脚本及其索引；
• 采集阶段：1.3.6.1.4.1.14988.1.1.18.{#SNMPINDEX}—— 对应脚本执行相关的叶子节点，按脚本索引访问，即向 RouterOS 请求执行该脚本并返回其输出结果。

可以这样理解完整链路：

Zabbix SNMP agent └─ discovery[{#SNMPVALUE}, 1.3.6.1.4.1.14988.1.1.8] → 枚举脚本名 → {#SNMPINDEX}/{#SNMPVALUE} └─ 1.3.6.1.4.1.14988.1.1.18.{#SNMPINDEX} → 按索引触发/读取脚本执行结果 └─ item key: ExecScript.[{#SNMPINDEX}] → 每个脚本一个监控项

该设计有一个显著优点：新增脚本无需改动模板。只要在 RouterOS 上创建符合命名规则的脚本，下一轮 LLD（默认 30 秒）即可自动发现并创建对应监控项。

三、发现规则（Discovery Rule）逐项拆解

模板唯一的发现规则名为Scripts，类型为SNMP agent。完整配置如下（取自 6.0 版 YAML 第 28–42 行）：

discovery_rules: - uuid: 9693f599c31d499ba4172a94a55ab3d8 name: Scripts type: SNMP_AGENT snmp_oid: 'discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.8]' key: MikScript delay: '30' filter: evaltype: AND conditions: - macro: '{#SNMPVALUE}' value: ^Get formulaid: A

各字段含义与实操要点：

关键点：如何定制匹配规则？修改条件中的value即可，例如：

• 只发现名称以Get开头的脚本（默认）：^Get；
• 发现所有脚本：将条件删除或改为空值；
• 发现其他前缀，如以M_开头：^M_；
• 精确匹配某脚本：^GetUptime$（$表示字符串结尾锚点）。

LLD 产生的宏中，{#SNMPVALUE}承载脚本名称，{#SNMPINDEX}承载该脚本在 OID 表中的索引序号，二者共同驱动后续监控项原型。

四、监控项原型（Item Prototype）与执行结果采集

发现规则下挂载了一个监控项原型，配置如下（6.0 版 YAML 第 43–50 行）：

item_prototypes: - uuid: ccd0bb713349448883896637f32f716f name: 'Execution of {#SNMPVALUE}' type: SNMP_AGENT snmp_oid: '1.3.6.1.4.1.14988.1.1.18.{#SNMPINDEX}' key: 'ExecScript.[{#SNMPINDEX}]' delay: '300'

该原型没有定义value_type预处理步骤，即默认按采集到的原始值存储；脚本输出通常为字符串（如状态文本）或数值，若脚本输出的是数值型指标，建议在导入后按需为该原型补充预处理（如value_type调整为 Numeric、追加单位或正则提取），以便直接用于触发器阈值判断和绘图。

五、RouterOS 侧准备与脚本编写

要让模板真正工作，需要先在 RouterOS 上完成三件事（此为通用 RouterOS 操作，与模板版本无关）：

1. 开启 SNMP 服务：/snmp set enabled=yes contact=... location=...，并设置 community（如public），同时配置 Zabbix 主机的访问 ACL，保证 Zabbix server/proxy 可以 walk14988.1.1.8与读取14988.1.1.18.x。

2. 创建以Get开头的脚本：

   /system script add name=GetUptime source=":put [/system resource get uptime];"

   脚本名必须以Get开头才能被模板默认过滤器发现；脚本的source中建议用:put输出结果，使脚本返回值可被 SNMP 采集到有意义的内容。

3. 验证 SNMP 可读性：在 Zabbix server 上可用snmpwalk -v2c -c public <router_ip> 1.3.6.1.4.1.14988.1.1.8检查脚本名表是否可见（该步骤用于排障，属实际操作验证，非模板内嵌内容）。

注意：脚本执行本身的耗时与 RouterOS 版本对 SNMP 子代理的支持程度会影响采集稳定性，建议在目标 RouterOS 版本上先用 snmpwalk/snmpget 实测后再批量上线。

六、Zabbix 侧导入与使用验证

导入模板

在 Zabbix 前端依次进入Configuration → Templates → Import，选择对应版本的导出文件：

• Zabbix 6.0：导入 6.0/template_mikrotik_script_execution_via_snmp.yaml；
• Zabbix 5.4：导入 5.4/template_mikrotik_script_execution_via_snmp.yaml；
• Zabbix 5.0：导入 5.0/template_mikrotik_script_execution_via_snmp.xml。

导入成功后，将模板链接到对应 MikroTik 主机的 Templates 标签页，并在主机上正确配置 SNMP 接口（IP、端口 161、community、SNMP 版本），模板即开始工作。

验证链路

1. LLD 生效：主机 →Discovery rules，确认Scripts规则状态为 Enabled，查看Latest data中MikScript返回的宏值应包含GetUptime等以Get开头的脚本名；
2. 监控项生成：进入Items，应能看到按脚本名展开的Execution of GetUptime等监控项，key 为ExecScript.[x]；
3. 数据采集：在Monitoring → Latest data中查看对应监控项最近一次采集值，确认脚本输出被正确入库；
4. 绘图与告警：为监控项添加图形，或基于其值创建触发器（模板本身未内置触发器，见下文）。

七、扩展建议：从采集到告警

模板本身不含触发器（README 与 YAML 中 Triggers 均为空），这意味着它只负责"采数"，告警需要使用者自行补充。结合模板的监控项结构，可以给出以下扩展方向（基于模板既有数据，属使用建议而非模板内事实）：

• 数值型指标告警：若脚本输出数值（如在线用户数、信号强度），可将对应监控项value_type调整为 Numeric，然后创建触发器，例如当last(/主机名/ExecScript.[1]) > 阈值时告警；
• 状态型指标告警：若脚本输出状态文本，可利用 Zabbix 正则或预处理转换为数值后参与触发器表达式；
• 批量告警：借助last_foreach()聚合函数（Zabbix 5.4+）对ExecScript.*系列监控项统一判警，避免逐项手写触发器；
• 宏参数化：模板声明"无宏"，如需统一调整轮询频率或 community，可在模板级或主机级自行增加宏（如{$SNMP_COMMUNITY}），再在监控项中引用。

八、已知限制与注意事项

基于模板结构与仓库事实，使用中需留意以下几点：

1. 脚本命名强约束：默认过滤器^Get决定了只有Get前缀脚本会被发现；改名前需同步调整模板过滤器，否则新脚本不会出现在 LLD 结果中；
2. 轮询频率固定：LLD 为 30 秒、采集为 300 秒，属模板写死的默认值；若脚本执行代价高或指标时效性要求强，可在导入后调整 delay；
3. 无内置告警：模板不提供触发器，开箱即用只能实现发现与采集，告警需自行配置；
4. 版本差异：5.0 版为 XML 导出，5.4/6.0 版为 YAML 导出，导入时请选择与 Zabbix 版本匹配的文件；模板主体逻辑在三版间一致，可交叉对照 5.4 YAML 与 5.0 XML 验证；
5. 执行语义依赖 RouterOS：采集 OID14988.1.1.18的读写行为与 RouterOS 版本相关，建议在目标固件上先做 SNMP 读写实测，确认脚本可被触发并返回结果后再规模化部署。

结语

Mikrotik Script Execution是一个"小而精"的 SNMP LLD 模板：用一条发现规则 + 一个监控项原型，就把 RouterOS 上任意符合命名规则的自定义脚本变成 Zabbix 的可绘图、可告警监控指标，且对脚本增删完全动态适配。对于依赖 RouterOS 脚本输出业务指标的运维场景，它提供了一个低成本、高扩展的采集骨架——将精力集中在脚本本身的质量与告警策略上即可。模板完整定义见 6.0 版 YAML 导出，其 LLD 与 OID 设计也可作为同类"脚本型 SNMP 模板"的参考范式。