4 SNMP OID 发现

概述

在本节中，我们将在一个 SNMP 设备上执行 low-level discovery。

自 Zabbix server/proxy 6.4 起，已支持 SNMP OID 的此发现方法。

示例配置

1. 创建一个SNMP agent 监控项，键值如下：

walk[.1. 3. 6. 1. 4. 1. 9999. 1. 1. 1. 1]

该监控项执行单次SNMP表遍历，并以符合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 = 200

2. 创建发现规则：

• 在名称字段中，输入描述性发现规则名称（例如"发现传感器"）。
• 在类型字段中，选择"依赖监控项"。
• 在键字段中，输入描述性键值（例如"net.if.discovery"）。
• 在主监控项字段中，选择"SNMP遍历监控项"。

3. 在预处理选项卡中，添加一个预处理步骤，从名称下拉菜单中选择"SNMP遍历转JSON"，并配置3参数：

• 字段名: "{#SENSORNAME}"；OID前缀: ".1. 3. 6. 1. 4. 1. 9999. 1. 1. 1. 1. 1"；格式: "保持原样"。
• 字段名: "{#SENSORTYPE}"；OID前缀: ".1. 3. 6. 1. 4. 1. 9999. 1. 1. 1. 1. 2"；格式: "保持原样"。
• 字段名: "{#SENSORVALUE}"；OID前缀: ".1. 3. 6. 1. 4. 1. 9999. 1. 1. 1. 1. 3"；格式: "保持原样"。

预处理后，发现规则将返回宏集合的JSON array。

例如：

[
           {
               "{#SNMPINDEX}": "1",
               "{#SENSORNAME}": "Temperature Sensor",
               "{#SENSORTYPE}": "temp",
               "{#SENSORVALUE}": "100"
           },
           {
               "{#SNMPINDEX}": "2",
               "{#SENSORNAME}": "Humidity Sensor",
               "{#SENSORTYPE}": "humidity",
               "{#SENSORVALUE}": "200"
           }
       ]

每个object代表一个被发现的传感器，并提供诸如{#SNMPINDEX}、{#SENSORNAME}、{#SENSORTYPE}和{#SENSORVALUE}等宏。

它们按SNMP索引分组，该索引是每个OID末尾的数字后缀（例如.1, .2）——此索引唯一标识SNMP表中的每一行，并自动提取为{#SNMPINDEX}。

4. 在发现规则下，create一个或多个监控项原型（将发现规则作为主监控项）。

例如，传感器值依赖监控项：

• 在名称字段中，输入"传感器{#SNMPINDEX}: {#SENSORNAME}"。
• 在类型字段中，选择"依赖监控项"。
• 在键字段中，输入"sensor.value[{#SNMPINDEX}]"。
• 在主监控项字段中，选择"SNMP遍历监控项"。

在预处理选项卡中，添加一个名为"SNMP遍历值"的预处理步骤，在参数字段中填写".1. 3. 6. 1. 4. 1. 9999. 1. 1. 1. 1. 3. {#SNMPINDEX}" OID。 格式: "保持原样"。

将发现以下监控项：

当发现规则运行时，会创建诸如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[1.3.6.1.2.1.2.2.1.10]

执行SNMP遍历至JSON预处理后，结果可能如下所示：

[
           {
               "{#SNMPINDEX}": "2",
               "{#VALUE}": "123456"
           },
           {
               "{#SNMPINDEX}": "3",
               "{#VALUE}": "654321"
           }
       ]

一个依赖的监控项原型使用{#SNMPINDEX}宏来构建键值：

net.if.in[{#SNMPINDEX}]

该原型的预处理操作包括在参数字段中使用OID为"1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}"的"SNMP遍历值"名称。
格式："未更改"。

运行时，实际的监控项如net.if.in[2]和net.if.in[3]会被创建。
如果某个接口索引发生更改（例如，在SNMP表中索引2被5取代），则在发现规则的下次run执行时：

• 旧的依赖项监控项 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遍历，依赖的监控项原型即可提取所需值。

发现的实体

当服务器运行时，它将根据 SNMP 发现规则返回的值来生成真实的依赖项 create、触发器和图形 监控项。