4 自动发现SNMP OIDs
概述
在本节中，我们将对一个 SNMP 设备执行低级别发现。
自 Zabbix 服务器/proxy 6.4 起，已支持这种基于 SNMP OID 的发现方法。
示例配置
1. 创建一个 SNMP agent 监控项，使用如下键值：
walk[.1.3.6.1.4.1.9999.1.1.1.1]
该监控项执行一次 SNMP 表 walk，并在一次请求中返回表中的所有条目，返回格式与 snmpwalk 工具在使用格式化选项 -Oe -Ot -On 时的输出一致。
它将返回如下多行文本值：
.1.3.6.1.4.1.9999.1.1.1.1.1.1 = STRING: "Temperature Sensor"
.1.3.6.1.4.1.9999.1.1.1.1.2.1 = STRING: "temp"
.1.3.6.1.4.1.9999.1.1.1.1.3.1 = 100
.1.3.6.1.4.1.9999.1.1.1.1.1.2 = STRING: "Humidity Sensor"
.1.3.6.1.4.1.9999.1.1.1.1.2.2 = STRING: "humidity"
.1.3.6.1.4.1.9999.1.1.1.1.3.2 = 2002. 创建一个发现规则：
- 在 Name 字段中，输入一个描述性的发现规则名称（例如，“Discover sensors”）。
- 在 Type 字段中，选择“Dependent item”。
- 在 Key 字段中，输入一个描述性的键值（例如，“net.if.discovery”）。
- 在 Master item 字段中，选择“SNMP walk item”。
3. 在 Preprocessing 选项卡中，添加一个预处理步骤，在 Name 下拉框中选择 “SNMP walk to JSON”，并配置 3 个参数：
- Field name：“{#SENSORNAME}”；OID prefix：“.1.3.6.1.4.1.9999.1.1.1.1.1”；Format：“Unchanged”。
- Field name：“{#SENSORTYPE}”；OID prefix：“.1.3.6.1.4.1.9999.1.1.1.1.2”；Format：“Unchanged”。
- Field name：“{#SENSORVALUE}”；OID prefix：“.1.3.6.1.4.1.9999.1.1.1.1.3”；Format：“Unchanged”。
预处理后，发现规则将返回一个由宏集合组成的 JSON 数组。
例如：
[
{
"{#SNMPINDEX}": "1",
"{#SENSORNAME}": "Temperature Sensor",
"{#SENSORTYPE}": "temp",
"{#SENSORVALUE}": "100"
},
{
"{#SNMPINDEX}": "2",
"{#SENSORNAME}": "Humidity Sensor",
"{#SENSORTYPE}": "humidity",
"{#SENSORVALUE}": "200"
}
]每个对象表示一个已发现的传感器，并提供诸如 {#SNMPINDEX}、{#SENSORNAME}、{#SENSORTYPE} 和 {#SENSORVALUE} 之类的宏。
它们按 SNMP 索引分组，该索引是每个 OID 末尾的数字后缀（例如 .1、.2）—— 该索引可唯一标识 SNMP 表中的每一行，并会自动提取为 {#SNMPINDEX}。
4. 在该发现规则下，创建一个或多个监控项原型（以发现规则作为 master item）。
例如，传感器值 dependent item：
- 在 Name 字段中，输入 “Sensor {#SNMPINDEX}: {#SENSORNAME}”。
- 在 Type 字段中，选择 “Dependent item”。
- 在 Key 字段中，输入 “sensor.value[{#SNMPINDEX}]”。
- 在 Master item 字段中，选择 “SNMP walk item”。
在 Preprocessing 选项卡中，添加一个预处理步骤，在 Name 中选择 “SNMP walk value”，并在 Parameter 字段中填写 OID “.1.3.6.1.4.1.9999.1.1.1.1.3.{#SNMPINDEX}”。 Format：“Unchanged”。
将发现以下监控项：
| Name | Key | 提取值的 OID | 监控项值 |
|---|---|---|---|
| Sensor 1: Temperature Sensor | sensor.value[1] | .1.3.6.1.4.1.9999.1.1.1.1.3.1 | 100 |
| Sensor 2: Humidity Sensor | sensor.value[2] | .1.3.6.1.4.1.9999.1.1.1.1.3.2 | 200 |
当发现规则运行时，将创建诸如 sensor.value[1]、sensor.value[2] 之类的监控项。
每个 dependent item 都通过预处理从 master item 的 SNMP walk 结果中提取其值，而无需自行执行单独的 SNMP 请求。
5. 在触发器原型中使用与发现规则相同的宏来引用 dependent item 原型。 例如：
{Template_Sensor:sensor.value[{#SNMPINDEX}].last()} > 75这将为每个已发现的传感器生成一个触发器（例如，sensor.value[1]、sensor.value[2]），并在最新值（温度或湿度）超过 75 时触发。
6. 为每个已发现的实体包含 dependent item。 图形监控项键值示例：
sensor.value[{#SNMPINDEX}]将为每个 {#SNMPINDEX} 创建一个图形，用于绘制温度和湿度随时间变化的曲线。
无论发现了多少个监控项，此配置在每个轮询周期内都只执行一次 SNMP walk 请求。 所有 dependent item 都通过预处理从 master SNMP walk 结果中提取其值，从而显著减少 SNMP 流量和负载。
使用 walk[] 的动态索引
动态索引（例如接口索引）可能会在硬件重新配置时发生变化。 为适应这种行为，可以创建一个主 SNMP walk 发现规则，并使用如下 key：
walk[1.3.6.1.2.1.2.2.1.10]在经过 SNMP walk to JSON 预处理后，结果可能类似于：
[
{
"{#SNMPINDEX}": "2",
"{#VALUE}": "123456"
},
{
"{#SNMPINDEX}": "3",
"{#VALUE}": "654321"
}
]一个依赖监控项原型使用 {#SNMPINDEX} 宏来构造 key：
net.if.in[{#SNMPINDEX}]此原型的预处理包含名称为 “SNMP walk value” 的步骤，并在 Parameter 字段中使用 OID “1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}”。 Format：“Unchanged”。
在运行时，将创建实际监控项，例如 net.if.in[2] 和 net.if.in[3]。
如果某个接口索引发生变化（例如，在 SNMP 表中索引 2 被 5 替换），那么在发现规则下一次运行时：
- 旧的依赖监控项 net.if.in[2] 会被标记为“丢失”或被移除，并且不再为该监控项采集新数据。
- 将创建新的依赖监控项 net.if.in[5]，并从空历史记录开始。
- net.if.in[2] 的历史数据不会自动迁移到 net.if.in[5]。
触发器原型示例：
{Template_Interface:net.if.in[{#SNMPINDEX}].last()} > 1000000000图形原型示例包含以下监控项：
net.if.in[{#SNMPINDEX}]
net.if.out[{#SNMPINDEX}]此配置可确保对具有动态索引的表进行可靠监控，同时尽量减少 SNMP 流量——每个轮询周期只需要执行一次 SNMP walk，而依赖监控项原型会提取所需的值。
已发现的实体
当服务器运行时，它将根据 SNMP 发现规则返回的值创建实际的依赖监控项、触发器和图形。