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 表遍历，并在一个请求中返回所有表条目，其格式与使用 -Oe -Ot -On 格式化选项运行 snmpwalk 工具的输出相对应。
它将返回以下多行文本值：
.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 字段中，输入描述性的发现规则名称（例如“发现传感器”）。
- 在 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 索引进行分组。SNMP 索引是每个 OID 末尾的数字后缀（例如 .1、.2）。此索引可唯一标识 SNMP 表中的每一行，并会自动提取为 {#SNMPINDEX}。
4. 在发现规则下创建一个或多个监控项原型（以发现规则作为主监控项）。
例如，传感器值依赖监控项：
- 在 Name 字段中，输入“Sensor {#SNMPINDEX}: {#SENSORNAME}”。
- 在 Type 字段中，选择“Dependent item”。
- 在 Key 字段中，输入“sensor.value[{#SNMPINDEX}]”。
- 在 Master item 字段中，选择“SNMP walk item”。
在 Preprocessing 选项卡中，添加一个预处理步骤，将名称设置为“SNMP walk value”，并在 Parameter 字段中输入 OID“.1.3.6.1.4.1.9999.1.1.1.1.3.{#SNMPINDEX}”。
Format：“Unchanged”。
将发现以下监控项：
| Name | Key | OID from which value is extracted | Item value |
|---|---|---|---|
| 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] 等监控项。
每个依赖监控项都通过预处理从主监控项的 SNMP 遍历结果中提取其值，而不会自行执行单独的 SNMP 请求。
5. 在触发器原型中引用依赖监控项原型，并使用发现规则中的相同宏。
示例：
{Template_Sensor:sensor.value[{#SNMPINDEX}].last()} > 75这将为每个发现的传感器创建一个触发器（例如 sensor.value[1]、sensor.value[2]），并在最新值（温度或湿度）超过 75 时触发。
6. 为每个发现的实体包含依赖监控项。
图形监控项键示例：
sensor.value[{#SNMPINDEX}]系统会为每个 {#SNMPINDEX} 创建一个图形，用于绘制温度和湿度随时间的变化。
无论发现的监控项数量是多少，此配置在每个轮询周期内只执行一次 SNMP 遍历请求。
所有依赖监控项都通过预处理从主 SNMP 遍历结果中提取其值，从而显著减少 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 发现规则返回的值创建实际的依赖监控项、触发器和图形。