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。 格式: "保持原样"。

将发现以下监控项:

名称 提取值的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]等监控项。

每个依赖监控项通过预处理从主监控项的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表中索引25取代),则在发现规则的下次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、触发器和图形 监控项。