.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 = 200

2. 创建一个发现规则：

在 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 索引进行分组。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 发现规则返回的值创建实际的依赖监控项、触发器和图形。

Docs

SNMP OID 的发现

概述

示例配置

使用 walk[] 的动态索引

已发现的实体

建议编辑

建议一个示例

谢谢！