4. Обнаружение SNMP OID'ов

Обзор

В этом разделе мы будем выполнять SNMP обнаружение на коммутаторе.

Этот метод обнаружения SNMP OID'ов поддерживается, начиная с Zabbix сервера/прокси версии 6.4.

Пример настройки

1. Создайте элемент данных с типом SNMP агент и ключом наподобие следующего:

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. Создайте правило обнаружения:

• В поле Имя (Name) введите наглядное имя правила обнаружения (например: «Discover sensors (Обнаружение датчиков)»).
• В поле Тип (Type) выберите «Зависимый элемент данных (Dependent item)».
• В поле Ключ (Key) введите наглядный ключ (например: «net.if.discovery»).
• В поле Основной элемент данных (Master item) выберите «SNMP walk item».

3. На вкладке Предобработка (Preprocessing) добавьте шаг предобработки «SNMP walk в JSON (SNMP walk to JSON)» в выпадающем списке Имя (Name) с тремя параметрами:

• Имя поля (Field name): "{#SENSORNAME}"; Префикс OID (OID prefix): ".1.3.6.1.4.1.9999.1.1.1.1.1": Формат (Format): «Без изменений (Unchanged)».
• Имя поля (Field name): "{#SENSORTYPE}"; Префикс OID (OID prefix): ".1.3.6.1.4.1.9999.1.1.1.1.2": Формат (Format): «Без изменений (Unchanged)».
• Имя поля (Field name): "{#SENSORVALUE}"; Префикс OID (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. Под правилом обнаружения создайте один или более прототипов элементов данных (с элементом данных правила обнаружения в качестве основного элемента данных).

Например, зависимый элемент данных для значения датчика:

• В поле Имя (Name) введите: «Sensor {#SNMPINDEX}: {#SENSORNAME}».
• В поле Тип (Type) выберите: «Зависимый элемент данных (Dependent item)».
• В поле Ключ (Key) введите: «sensor.value[{#SNMPINDEX}]».
• В поле Основной элемент данных (Master item) выберите: «SNMP walk item».

На вкладке Предобработка (Preprocessing) добавьте шаг предобработки «Значение SNMP walk (SNMP walk value)» в поле имени с OID'ом «.1.3.6.1.4.1.9999.1.1.1.1.3.{#SNMPINDEX}» в поле Параметр (Parameter). Формат (Format): «Без изменений (Unchanged)».

Будут обнаружены следующие элементы данных:

При отрабатывании правила обнаружения создаются элементы данных — такие, как sensor.value[1], sensor.value[2].

Каждый зависимый элемент данных с помощью предобработки извлекает своё значение из результата SNMP walk основного элемента данных, без выполнения отдельных самостоятельных SNMP запросов.

5. В прототипах триггеров ссылайтесь на прототипы зависимых элементов данных, используя те же макросы из правила обнаружения. Пример:

{Template_Sensor:sensor.value[{#SNMPINDEX}].last()} > 75

Это создаёт триггер для каждого обнаруженного датчика (например, sensor.value[1], sensor.value[2]), срабатывающий, если последнее значение (температура или влажность) превышает 75.

6. Включайте зависимые элементы данных для каждого обнаруженного объекта. Пример ключа элемента данных для графика:

sensor.value[{#SNMPINDEX}]

Создаётся по графику на каждый {#SNMPINDEX}, выстраивая график температуры и влажности с течением времени.

Такая настройка выполняет только один запрос SNMP walk на цикл опроса, независимо от количества обнаруженных элементов данных. Все зависимые элементы данных извлекают свои значения из результата основного SNMP walk с помощью предобработки, значительно уменьшая SNMP трафик и нагрузку.

Динамические индексы с walk[]

Динамические индексы (например, индексы интерфейсов) могут сдвигаться при изменениях конфигурации оборудования. Чтобы приспособиться к такому поведению, основное правило обнаружения SNMP walk создаётся с ключом таким как:

walk[1.3.6.1.2.1.2.2.1.10]

После предобработки SNMP walk в JSON результат может быть наподобие:

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

Прототип зависимого элемента данных использует макрос {#SNMPINDEX}, чтобы сконструировать свой ключ:

net.if.in[{#SNMPINDEX}]

Предобработка для этого прототипа включает шаг «Значение SNMP walk (SNMP walk value» в поле имени с OID'ом «1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}» в поле Параметр (Parameter). Формат (Format): «Без изменений (Unchanged)».

Во время выполнения создаются реальные элементы данных — такие, как net.if.in[2] и net.if.in[3]. Если индекс данного интерфейса меняется (например, если индекс 2 заменяется в таблице SNMP на 5), то при следующем срабатывании правила обнаружения:

• Старый зависимый элемент данных net.if.in[2] помечается как «потерянный (lost)» или удаляется, и никакие новые данные для него не собираются.
• Создаётся новый элемент данных 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.